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Abstract 


This  report  contains  the  proceedings  of  the  First  Workshop  on  Service-Oriented  Architectures  and 
Product  Lines  (SOAPL)  2007  that  was  held  on  September  1 0th,  2007  in  Kyoto,  Japan  as  part  of 
the  2007  Software  Product  Line  Conference  (SPLC  2007).  This  report  includes  an  overview  of  the 
workshop,  four  invited  presentations,  details  of  the  workshop’s  outcomes,  and  the  workshop  posi¬ 
tion  papers. 
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1  Introduction 


Service-oriented  architecture  (SOA)  and  software  product  line  (SPL)  approaches  to  software  de¬ 
velopment  share  a  common  goal.  They  both  encourage  an  organization  to  reuse  existing  assets 
and  capabilities  rather  than  repeatedly  redeveloping  them  for  new  systems.  These  approaches  en¬ 
able  organizations  to  capitalize  on  reuse  to  achieve  desired  benefits  such  as  productivity  gains, 
decreased  development  costs,  improved  time  to  market,  higher  reliability,  and  competitive  advan¬ 
tage.  Their  distinct  goals  may  be  stated  as 

•  SOA:  “enable  assembly,  orchestration  and  maintenance  of  enterprise  solutions  to  quickly 
react  to  changing  business  requirements”  1 

•  SPL:  systematically  capture  and  exploit  commonality  among  a  set  of  related  systems  while 
managing  variations  for  specific  customers  or  market  segments 

The  First  Workshop  on  Service-Oriented  Architectures  and  Product  Lines  (SOAPL)  2007  ex¬ 
plored  the  connections  from  two  perspectives: 

1 .  Can  services  support  product  lines  using  a  service-oriented  architecture? 

2.  How  can  use  of  product  line  practices  support  services  and  service-oriented  architectures? 

1.1  ABOUT  THIS  REPORT 

This  report  captures  the  information  presented  and  discussed  during  SOAPL  2007.  Section  2  out¬ 
lines  the  workshop  organization  and  format,  Section  3  summarizes  the  presentations,  Section  4 
presents  additional  discussion  topics,  and  Section  5  presents  workshop  outcomes.  Appendices  A 
through  E  contain  the  accepted  workshop  papers,  which  appear  as  they  did  upon  acceptance  ex¬ 
cept  for  minor  editorial  and  formatting  changes. 


1  Wienands,  Christoph.  “Studying  the  Common  Problems  with  Service-Oriented  Architecture  and  Software  Product 
Lines.”  Service-Oriented  Architecture  (SOA)  &  Web  Services  Conference.  Atlanta,  GA,  October  2006. 
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2  Workshop  Organization  and  Format 


2.1  WORKSHOP  ORGANIZATION 

Sections  2.1.1  through  2.1.3  below  list  the  people  who  organized,  facilitated,  and  participated  in 
SOAPL  2007. 

2.1.1  Organizers 

•  Sholom  Cohen,  Carnegie  Mellon 5  Software  Engineering  Institute  (SEI),  USA, 
sgc@sei.cmu.edu 

•  Paul  Clements,  SEI,  USA,  clements@sei.cmu.edu 

•  Andreas  Helferich,  Universitat  Stuttgart,  Germany,  helferich@wi.uni-stuttgart.de 

•  Robert  Krut,  SEI,  USA,  rk@sei.cmu.edu 

•  Grace  Lewis,  SEI,  USA,  glewis@sei.cmu.edu 

•  Dennis  Smith,  SEI,  USA,  dbs@sei.cmu.edu 

•  Christoph  Wienands,  Siemens  Corporate  Research,  USA,  christoph.wienands@siemens.com 

2.1.2  Facilitator 

•  Robert  Krut,  Software  Engineering  Institute,  USA,  rk@sei.cmu.edu 

2.1.3  Participants 

•  David  Benavides,  University  of  Seville,  Spain,  benavides@tdg.lsi.us.es 

•  Masayoshi  Hagiwara,  Microsoft,  Japan,  masayh@microsoft.com 

•  Andreas  Helferich,  Universitat  Stuttgart,  Germany,  helferich@wi.uni-stuttgart.de 

•  Jean-Narc  Jezequel,  University  of  Rennes,  INRIA,  France,  Jean-Narc.Jezequel@inria.fr 

•  Larry  Jones,  Software  Engineering  Institute,  USA,  lgj@sei.cmu.edu 

•  Christian  Kastner,  University  of  Magdeburg,  Germany,  ckaestne@uni-magdeburg.de 

•  Dan  Lee,  ICU,  Korea,  danlee@icu.ac.kr 

•  JaejoonLee,  Lancaster  University,  U.K.,  j.lee@comp.lancs.ac.uk  (Fraunhofer  Institute  for 
Experimental  Software  Engineering  (IESE)  in  Frankfurt  at  the  time  of  his  participation) 

•  Tomi  Mannisto,  Helsinki  University  of  Technology,  Finland,  tomi.mannisto@tkk.fi 

•  Shuhei  Nojiri,  Hitachi,  Japan,  shuhei.nojri.dd@hitachi.com 

•  Mikko  Raatikainen,  Helsinki  University  of  Technology,  Finland,  mikko.raatikainen@tkk.fi 

•  Ktar  Sato,  DENSO,  Japan,  ktar@bof.jp 


Carnegie  Mellon  is  registered  in  the  U.S.  Patent  and  Trademark  Office  by  Carnegie  Mellon  University. 
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2.2  WORKSHOP  FORMAT 


The  workshop  format  was  highly  interactive  and  focused  on  making  tangible  progress  towards 
answering  the  two  questions  relating  to  the  connections  between  SOA  and  product  lines.  The  ac¬ 
cepted  papers  provided  the  key  issues  relating  to  the  workshop  theme:  “Service-Oriented  Archi¬ 
tectures  and  Product  Lines  -  What  Is  the  Connection?”  The  breakdown  of  the  papers  into  topical 
areas  helped  us  set  up  topics  for  discussion  at  the  workshop.  The  paper  topics  broke  down  into 
three  areas: 

1 .  methods  for  SOA  and  product  line  development 

2.  managing  service  features  and  variability 

3.  examples  of  applications 

The  morning  session  featured  presentations  based  on  position  papers  (Section  3).  At  least  one  pa¬ 
per  was  presented  for  each  topic  area.  Presentations  were  limited  to  1 5  minutes  followed  by  dis¬ 
cussion. 

The  afternoon  session  provided  an  opportunity  for  the  group  to  continue  discussing  the  identified 
topic  areas  or  to  identify  new  topics  based  on  the  dynamics  and  interests  of  the  group.  The  group 
identified  six  topics  to  discuss  for  the  afternoon  session  (see  Section  4). 
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3  Workshop  Papers  and  Presentations 


3.1  PAPERS 

The  workshop  organizers  accepted  the  following  five  papers,  each  of  which  appears  in  an  appen¬ 
dix  of  this  report. 

3.  Appendix  A:  Software  Product  Lines  and  Service-Oriented  Architecture:  A  Systematic 
Comparison  of  Two  Concepts 

4.  Appendix  B:  A  Taxonomy  of  Variability  in  Web  Service  Flows 

5.  Appendix  C:  Comparison  of  Service  and  Software  Product  Family  Modeling 

6.  Appendix  D:  Identifying  and  Specifying  Reusable  Services  of  Service  Centric  Systems 
Through  Product  Line  Technology 

7.  Appendix  E:  Product  Lines  that  Supply  Other  Product  Lines:  A  Service-Oriented  Approach 

In  addition  to  the  papers,  the  organizers  accepted  one  website  as  a  contribution,  which  addresses 
the  relationship  between  SOA  and  SPL:  A  Framework  for  Software  Product  Line  Practice,  Ver¬ 
sion  5.0,  FAQ  (http://www.sei.cmu.edu/productlines/frame  report/FAQ. htm#other  approaches) 
[SEI  2007a], 

3.2  PRESENTATIONS 

Four  papers  were  presented  during  the  workshop  morning  session  and  are  described  below  in  Sec¬ 
tions  3.2.1  through  3.2.3.  Each  presentation  is  listed  by  the  topic  area  identified  by  the  workshop 
organizers.  A  brief  overview  of  the  presentation  is  included  as  well  as  questions  submitted  by  the 
workshop  organizers  prior  to  the  presentations. 

The  complete  presentations  are  provided  on  the  SOAPL  2007  website 
(http://www.sei.cmu.edu/productlines/SOAPL/)  [SEI  2007b]. 

3.2.1  Methods  for  SOA  and  Product  Line  Development 

Mikko  Raatikainen  made  the  presentation  for  the  first  topic  area.  Mikko  is  from  the  Helsinki  Uni¬ 
versity  of  Technology,  Finland,  and  co-authored  the  paper  he  presented:  Comparison  of  Service 
and  Software  Product  Family  Modeling. 

The  presentation  began  with  a  brief  discussion  of  the  similarities  and  differences  between  soft- 
ware  product  families  (SPFs)  and  service-oriented  computing.  They  are  similar  in  that  they  both 
involve  developing  applications  from  existing  software  and  a  reliance  on  modeling.  They  differ  in 
that  service-oriented  computing  involves  dynamic  computational  elements  whereas  SPFs  typically 
comprise  static  elements  (i.e.,  dynamic  binding  versus  static). 


2  Software  product  families  were  equated  to  software  product  lines  as  defined  by  Clements  [Clements  2001], 
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The  main  body  of  the  presentation  examined  and  compared  the  modeling  methods  of  SPFs  and 
service-oriented  computing.  SPF  family  modeling  focuses  on  domain  models  which  include  vari¬ 
ability  models  and  product  models.  SPF  modeling  employs  many  approaches  such  as  Feature- 
Oriented  Domain  Analysis  and  extensions  to  existing  approaches  such  as  UML.  Service-oriented 
computing  modeling  focuses  on  modeling  approaches  for  web  services,  since  web  services  are 
currently  the  dominant  implementation  of  service-oriented  computing.  Modeling  of  web  services 
is  typically  driven  by  standards  such  as  Web  Service  Definition  Language  (WSDL)  and  Business 
Process  Execution  Language  (BPEL).  The  notation  is  usually  Extensible  Markup  Language 
(XML). 

The  noted  comparisons  between  the  modeling  methods  are 

•  Services  involve  no  domain  or  variability  modeling  while  SPFs  do. 

•  Services  tend  to  be  compositional  while  SPFs  tend  to  be  top  down. 

•  Both  focus  on  architectural  entities.  However,  SPFs  typically  focus  on  static  entities  whereas 
service-oriented  computing  models  typically  focus  on  dynamic  entities. 

•  SPFs  are  much  broader  in  focus  at  the  architectural  level  while  modeling  in  service-oriented 
computing  tends  to  focus  on  the  behavior  of  the  system. 

•  Service-oriented  computing  models  employ  an  XML  notation,  while  SPF  modeling  typically 
uses  a  graphical  notation. 

The  presentation  concluded  with  suggestions  of  future  directions  for  combining  the  two  modeling 
approaches: 

•  The  feasibility  of  variability  modeling  for  service-oriented  computing  should  be  studied. 

•  Variability  modeling  in  SPFs  should  be  extended  to  include  lessons  learned  from  behavior 
modeling  and  analysis  of  services  and  business  processes. 

•  The  necessary  approach  for  modeling  of  services  and  SPFs  should  be  studied  more  thor¬ 
oughly. 

The  workshop  organizers  submitted  the  following  questions  prior  to  the  presentation. 

Questions:  “Could  criteria  from  the  SEI  Service  Migration  and  Reuse  Technique  (SMART)  serve 
as  an  approach  for  the  migration  of  legacy  components  for  product  lines?  What  specific  criteria 
would  apply  here?  Are  there  detailed  examples  or  a  comparison  of  models  (e.g,  feature  models 
versus  SDL/BPEL/Business  Process  modeling  notation  (BPMN)?” 

Response:  The  authors  were  not  familiar  with  specific  examples  of  SMART’S  application  to  leg¬ 
acy  systems.  They  were  also  not  aware  of  any  detailed  examples  or  a  comparison  of  models. 

The  presenter  pointed  out  that  SPFs  were  intra-organizational  whereas  the  use  of  services  is  ex¬ 
ternal.  The  presenter  reiterated  that  there  was  a  relative  tendency  for  a  static  focus  in  SPFs  versus 
a  dynamic  focus  for  service-oriented  computing.  His  team  had  tried  to  apply  its  SPF  modeling 
tools  (KumbangTools)  to  service  composition  with  some  success  [KumbangTools  2008].  They 
were  not  suitable  for  complex  behavior. 
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The  presenter  felt  that  future  efforts  should  focus  on 

•  the  creation  of  standards  for  SPLs  similar  to  those  being  worked  on  with  services 

•  the  working  implementation  of  SPF  modeling  tools  in  service-oriented  computing 

•  more  interplay  between  research  and  practice 

3.2.2  Managing  Service  Features  and  Variability 

David  Benavides  made  the  presentation  for  the  second  topic  area.  David  is  from  the  University  of 
Seville,  Seville,  Spain,  and  co-authored  the  paper  he  presented:  A  Taxonomy  of  Variability  in  Web 
Service  Flows. 

This  presentation  provided  a  brief  discussion  of  how  SPL  practices  can  be  used  to  support  service- 
oriented  applications.  Since  the  most  common  implementation  of  service-oriented  applications  is 
web  services,  this  presentation  primarily  focused  on  how  to  manage  variability  in  web  services,  in 
the  context  of  SPL  and  SOA,  by  defining  a  Web  Service  Flow  (WS-flow)  and  identifying  vari¬ 
ability  points  in  WS-flows.  This  research  provides  a  starting  point  for  a  base  of  knowledge  about 
variability  in  WS-flows.  It  can  be  used  further  for  evaluating  the  different  mechanisms  for  imple¬ 
menting  variability  in  WS-flows  and  identifying  factors  that  affect  the  selection  of  such  variability 
mechanisms. 

A  WS-flow  is  a  composite  web  service  that  is  implemented  through  use  of  a  process-based  ap¬ 
proach.  A  WS-flow  specifies  a  set  of  tasks  that  are  executed  by  the  participants  of  a  process  and 
defines  the  execution  order  of  tasks,  the  data  exchange  among  the  participants,  and  the  business 
rules.  The  language  used  to  define  WS-flows  is  BPEL. 

In  this  body  of  work,  identification  of  variability  points  in  WS-flows  was  limited  to  service  invo¬ 
cation  and  the  process  workflow  structure.  The  presenter  defined  a  service  invocation  as  “an  ac¬ 
tivity  in  which  workflow  invokes  another  service  and  exchanges  messages  with  it  returning  con¬ 
trol  back  to  the  workflow.”  The  process  workflow  structure  “determines  all  the  aspects  related  to 
the  way  in  which  the  process  is  executed:  the  execution  order,  the  data  exchanged  between  par¬ 
ticipants,  the  business  rules,  the  errors  treatment,  etc.” 

The  presentation  provided  a  feature  model  summarizing  the  variability  points  in  the  invocation  of 
services,  as  shown  in  Figure  1. 
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Figure  1:  Variability  Points  in  Service  Invocation 

The  four  main  variability  points  identified  were:  1)  binding  time,  2)  partner  selection  criteria,  3) 
message  exchange,  and  4)  protocols.  Binding  time  offers  the  selection  of  services  to  be  invoked  at 
design  time  or  runtime  where  runtime  is  further  divided  into  user  driven  and  automated.  Partner 
selection  criteria  helps  to  determine  which  of  the  available  services  offering  the  same  functional¬ 
ity  will  be  selected  for  invocation.  Evaluation  context  enables  the  selection  criteria  to  be  hard 
coded  or  delegated.  Definition  time  enables  the  selection  criteria  to  be  modified  at  design  time  or 
runtime.  Messages  exchanged  between  service  workflows  and  services  may  be  synchronous  or 
asynchronous.  Four  different  protocols  may  be  used  for  service  interactions  over  the  network. 

The  two  main  variability  points  in  process  workflow  structure  are  control  flow  and  data  flow. 
Control  flow  is  the  workflow  structure  that  determines  the  tasks  to  be  executed  and  the  execution 
order.  Data  flow  covers  the  exchange  of  data  between  services. 

The  presentation  concluded  with  the  reiteration  that  there  is  a  need  for  a  classification  of  variabil¬ 
ity  points  in  WS-flow  to  serve  as  a  starting  point  for  handling  variability  through  services  in  the 
context  of  SPLs  and  SOA.  Future  work  will  look  at  implementation  technologies — paying  par¬ 
ticular  attention  to  the  ways  in  which  they  support  the  variability  points  presented — leading  to  a 
service-based  development  of  business-driven  SPFs. 

The  workshop  organizers  submitted  the  following  questions  prior  to  the  presentation. 

Questions:  “Where  an  application  in  an  SOA-based  product  line  is  built  using  services  from  ex¬ 
ternal  core  asset  sources,  how  would  product  development  manage  variability  and  selection 
of  variation  of  features  within  those  assets?  Could  entire  services  be  substituted?  Are  there  varia¬ 
tions  within  a  service?  Is  there  any  implementation  of  the  taxonomy?” 

Response:  In  their  work,  the  authors  don’t  have  an  implementation  yet,  so  they  are  not  sure  how 
product  development  would  manage  variability  and  selection  of  variation  of  features  within  those 
assets  or  how  to  automate  the  feature  model.  Their  research  currently  examines  the  relationship 
between  SPFs  and  SOA. 

3.2.3  Application  Examples 

Two  presentations  were  made  for  the  third  topic  area.  Jaejoon  Fee  made  the  first  presentation. 
Jaejoon  worked  at  the  Fraunhofer  Institute  for  Experimental  Software  Engineering  (IESE)  at  the 
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time  of  this  presentation  and  now  can  be  contacted  at  Lancaster  University  in  the  U.K.  He  co¬ 
authored  the  paper  he  presented:  Identifying  and  Specifying  Reusable  Services  of  Service  Centric 
Systems  Through  Product  Line  Technology. 


This  presentation  provided  a  brief  discussion  on  the  challenges  of  dynamically  managing  services 
in  an  SOA-based  system  and  how  product  line  engineering  concepts  were  used  to  identify  and 
specify  reusable  services  based  on  features.  The  approach  to  identify  or  specify  reusable  services 
of  an  SOA-based  system  is  presented  in  Figure  2. 
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Figure  2:  Activities  for  Managing  Services  in  an  SOA-Based  System 

The  feature  and  feature  binding  analysis  organize  the  system  features  into  a  product  line  features 
model  that  includes  identified  binding  units  (representing  major  functionality  of  a  system)  and 
relative  binding  times.3  The  service  analysis  examines  the  feature  model  and  feature  binding  in¬ 
formation  to  identify  molecular  services  (computational-oriented  services  that  represent  a  prede¬ 
fined  task)  and  orchestrating  services  (behavior-oriented  services  that  define  a  sequence  of  tasks). 
The  molecular  services  are  the  basic  building  blocks,  reused  as-is  by  the  orchestrating  services. 
Molecular  services  are  self-contained  and  stateless,  have  pre-/post-conditions,  and  represent  do¬ 
main-specific  services.4’5  The  orchestrating  service  represents  a  workflow  for  dependable  orches¬ 
tration  of  molecular  services.  Each  workflow  is  based  on  a  service  behavior  specification  with 
pre-/post-conditions  and  invariants. 


To  illustrate  this  approach,  the  presenter  introduced  the  application  domain  “Virtual  Office  of  the 
Future.”  The  virtual  office  provides  workers  with  tools,  technology,  and  skills  to  perform  tasks  at 
any  time,  from  any  location.  The  presenter  walked  through  diagrams  for  molecular  service  identi¬ 
fication,  workflow  specification,  and  identification  of  tasks  from  a  workflow  specification  for  the 
virtual  office. 


3  Grouping  of  features  into  binding  units  of  the  same  binding  times  is  a  key  driver  for  identifying  reusable  services. 

4  Domain-specific  is  a  key  property  in  identifying  the  correct  level  of  granularity  of  a  service. 

5  Quality  of  service  is  defined  in  the  features  of  the  molecular  service. 
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The  workshop  organizers  submitted  the  following  question  prior  to  the  presentation. 

Question:  How  would  identified  services  be  used  in  applications?  Might  we  see  hybrid  service- 
/component-  oriented  applications?  What  evidence  is  there  of  an  actual  “right”  scale  of  granular¬ 
ity?  Do  case  study  artifacts  beyond  the  limited  figures  in  the  paper  actually  exist? 

Response:  The  authors  are  planning  to  prototype  the  virtual  office.  They  are  not  sure  about  a  hy¬ 
brid  service/component-oriented  application.  They  need  to  study  the  molecular  service  as  having 
the  right  level  of  granularity. 

Christian  Kastner  made  the  second  presentation  in  the  third  topic  area.  Christian  is  from  the  Uni¬ 
versity  of  Magdeburg,  Magdeburg,  Germany,  and  co-authored  the  paper  he  presented:  Product 
Lines  that  Supply  Other  Product  Lines:  A  Sendee-Oriented  Approach. 

This  presentation  provided  a  service-oriented  approach  to  combining  different  products  from  dif¬ 
ferent  product  lines  into  a  third  product  line,  yielding  more  elaborate  products.  The  approach  uses 
an  SOA  in  which  product  lines  are  regarded  as  services  that  are  consumed  by  service-oriented 
product  lines  (SOPLs). 

The  concept  of  a  SOPL  is  illustrated  through  a  “web  portals  of  portlets”  example.  A  portal  is  de¬ 
fined  as  an  “application  that  provides  centralized  access  to  a  variety  of  services.”  Portlets  are 
components  (services)  offered  by  a  third  party.  The  scenario  requires  that  a  product  line  consumes 
products  that  are  supplied  from  third-party  product  lines. 

In  this  example,  there  exists  a  two-fold  connection  between  product  lines  and  SOA.  First,  there 
exists  a  product  line  of  portals  that  enables  customer  portals  to  be  developed  from  customized 
portlets.  The  application  functionality  is  customized  by  using  product  lines  of  supplied  services, 
and  the  application  interface  is  customized  by  using  SOA  standards  to  consume  supplied  services. 
Second,  the  portals  may  be  customized  creating  a  product  line  of  portals.  Therefore,  not  only  is 
the  portlet  customized  from  a  product  line,  but  the  portal  is  as  well. 

How  can  a  software  product  line  automatically  request  and  consume  a  product  from  another  prod¬ 
uct  line?  The  vision  for  the  SOPL  is  the  integration  of  products  supplied  from  different  product 
lines  with  minimal  “human  intervention.”  Currently,  manual  integration  is  the  means  of  combin¬ 
ing  different  products  from  different  product  lines.  By  using  SOA,  product  developers  can  “ho¬ 
mogenize”  the  products  from  product  lines.  Therefore,  the  SOPL  can  be  used  to  automate  the  op¬ 
eration  of  a  software  product  line  by  automatically  requesting  and  consuming  products  from 
another  product  line. 

The  SOPL  relies  on  a  supplier/consumer  relationship  and  operations.  A  supplier  is  defined  as  a 
product  line  that  supplies  products  to  other  product  lines.  It  is  characterized  by  descriptive  infor¬ 
mation,  product  information  (including  feature  and  core  asset  information),  and  product  interface. 
A  consumer  is  a  product  line  that  consumes  products  from  supplier  product  lines.  Operations  in¬ 
volve  registration  (i.e.,  the  discovery  of  each  product  line  supplier)  and  consumption  (i.e.,  produc¬ 
tion  and  delivery  of  a  product)  based  on  the  existing  SOA  standardization  efforts  and  tool  support. 

The  web  portals  of  portlets  example  illustrated  the  idea  of  SOPL.  However,  more  work  must  be 
done  to  create  the  infrastructure  to  make  this  a  viable  approach  with  models,  tools,  and  so  forth. 
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Since  this  presentation  did  not  have  a  question  submitted  by  the  workshop  organizers  prior  to  the 
presentations,  the  authors  elected  to  answer  the  workshop  theme:  “Service-Oriented  Architectures 
and  Product  Lines  -  What  Is  the  Connection?” 

Question:  Service-Oriented  architectures  and  product  lines  -  what  is  the  connection? 

Response:  The  authors  believe  that  SOA  techniques  can  be  used  as  an  infrastructure  on  which  to 
build  increasingly  complex  software  product  line  systems.  Their  vision  is  to  facilitate  the  emer¬ 
gence  of  a  concurrent  market  where  atomic  products  from  supplier  product  lines  can  be  automati¬ 
cally  integrated  into  a  larger  product  line. 
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4  Additional  Discussion  Topics 


When  the  presenters  were  finished,  the  group  discussed  topics  that  arose  in  response  to  their  pres¬ 
entations.  The  discussions  followed  the  dynamics  and  interests  of  the  group  by  identifying  the 
following  five  topics: 

1.  What  are  the  possible  SOA-PL  connections? 

2.  What  are  the  issues  surrounding  dynamic  aspects  of  both  SOA  and  PLs? 

3.  What  is  a  reusable  service? 

4.  What  are  the  architectural  aspects  of  SPLs  versus  SOA? 

5.  What  is  the  scope  of  a  system  in  the  context  of  services? 

4.1  WHAT  ARE  THE  POSSIBLE  SOA-PL  CONNECTIONS? 

This  discussion  focused  on  two  topics: 

1 .  including  services  within  a  product  line  architecture 

2.  developing  a  service  as  a  product  line 

To  include  services  in  a  product  line,  developers  could  include  a  variation  point  in  the  architecture 
implemented  as  a  component  or  as  a  service.  A  specific  configuration  could  select  the  component 
or  the  service,  depending  on  the  specific  functional  or  quality  features  needed  by  the  application 
and  satisfied  by  each  alternate.  Services  in  this  context  could  address  possible  selection  features 
such  as 

•  a  need  for  dynamic  variation 

•  exploitation  of  the  availability  of  existing  services  where  appropriate 

•  use  of  Universal  Description  Discovery  and  Integration  (UDDI)  to  transfer  information  dur¬ 
ing  execution  for  service  selection 

•  rapid  construction  of  product  line  systems 

A  second  connection  could  be  designing  services  as  a  product  line.  In  this  context,  services  them¬ 
selves  would  be  configurable  according  to  architecture  variations  or  specific  features.  Possibly  a 
service  product  line  could  be  offered  in  a  marketplace,  where  an  organization  acquires  the  service 
outright  for  in-house  tailoring  or  commissions  the  SOA  product  line  developer  to  tailor  the  prod¬ 
uct  line  for  the  organization’s  use.  For  example,  the  SOA  product  line  may  be  a  mortgage  service 
product  line.  A  bank  or  other  lending  institution  could  acquire  access  to  a  specific  instance,  defin¬ 
ing  the  specializations  it  needs  to  the  SOA  product  line  developer.  Alternatively,  the  entire  prod¬ 
uct  line  capability  could  be  acquired,  and  the  bank  or  lending  institution  could  tailor  the  service  in 
multiple  ways  dependent  on  customer  categories,  local  banking  regulations,  or  other  variations. 

Many  of  the  organizational  issues  encountered  in  introducing  SOA  or  SPLs  are  similar.  While 
some  involve  technical  aspects — architecture,  testing,  integration — the  highest  risk  areas  tend  to 
be  organizational.  The  need  to  justify  investment,  train  developers,  and  operate  a  product 
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line/SOA  development  organization  involves  many  of  the  same  practice  areas.  A  sharing  of  case 
studies  based  on  real-world  examples  could  support  integrating  product  line  solutions  and  SOA 
solutions.  For  example,  both  SOA  and  product  lines  currently  suffer  from  limitations  on  reuse 
outside  the  immediate  development  organization.  Investigation  of  successful  uses  of  a  product 
line  or  SOA  across  an  enterprise  and  even  between  enterprises  could  support  the  SOA  and  product 
line  connection. 

4.2  DYNAMIC  ASPECTS— WHAT  ARE  THE  ISSUES? 

Much  of  this  discussion  focused  on  the  advantages  of  SOA  in  supporting  dynamic  execution.  The 
position  of  many  in  the  discussion  is  that  SOA  executes  dynamically,  by  definition,  while  compo¬ 
nent  technology  is  static.  However,  a  product  line  architecture  may  also  support  a  dynamic  varia¬ 
tion  mechanism  via  plug-ins  or  some  other  plug-and-play  architecture.  Dynamic  class  loading  in 
Java,  for  example,  allows  selection  of  classes  when  needed,  based  on  product  and  user  context  at 
the  time  of  class  selection.  Dynamic  link  libraries  and  reflection  offer  runtime  selection  for  varia¬ 
tion.  The  SOA  and  product  line  connection  can  benefit  from  the  sharing  of  experience  results  in 
this  area. 

The  group  also  proposed  that  a  perfonnance  penalty  comes  with  dynamic  selection  and  that  de¬ 
velopment  is  more  difficult.  However,  dynamics  can  also  reduce  complexity.  The  group  dis¬ 
cussed  printing  services  as  an  example.  An  application  may  support  dynamic  determination  of  a 
printer,  based  on  printing  needs  and  existing  conditions  such  as  queue  length  or  printer  condition. 

If  I  have  a  long  file  to  print,  the  application  may  determine  the  efficiency  of  waiting  for  a  faster 
printer  with  a  longer  queue  than  immediate  printing  where  there  is  no  wait.  The  printer  example 
may  be  overly  simplistic,  since  the  application  involved  is  by  definition  stateless — the  application 
“doesn’t  care”  what  print  services  have  been  previously  executed.  Other  services  may  perform 
differently  based  on  prior  execution,  where  caching  or  other  runtime  service  states  may  affect 
quality  of  service. 

In  a  pure  SOA  or  mixed  product  line/SOA,  other  dynamic  issues  emerge.  These  include  detection 
of  available  or  unavailable  services  and  responses  to  these  conditions.  Is  the  protocol  to  retry  or  to 
immediately  fall  back  to  an  alternative  service?  What  if  no  alternate  is  available  or  identified?  Also, 
can  an  existing  application  dynamically  integrate  services  with  new,  unforeseen  functionality? 

Testing  and  reliability  in  a  dynamic  environment  also  affect  validation.  A  tested  service  operates 
within  some  known  bounds,  but  dynamic  selection  may  pose  a  context  outside  the  tested  bounds. 
Does  the  service  continue  to  perform  within  its  “guaranteed  performance  parameters?”  How  does 
a  potential  service  user  confirm  or  at  least  measure  this  situation?  Third-party  services  in  general 
lead  to  uncertainty  for  the  user.  A  service  should  publish  its  assumed  pre-  and  post-conditions  for 
validation  of  services,  so  the  user  can  determine,  dynamically,  if  its  current  context  satisfies  these 
conditions.  If  the  current  context  does  not,  the  potential  service  user  looks  elsewhere. 

4.3  WHAT  IS  A  REUSABLE  SERVICE? 

The  paper  and  presentation  by  Jaejoon  Lee,  Identifying  and  Specifying  Reusable  Services  of  Ser¬ 
vice  Centric  Systems  Through  Product  Line  Technology,  makes  a  distinction  between  molecular, 
or  fine-grained,  components  and  behavior  or  orchestrating  services  that  manage  the  workflow  of 
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molecular  tasks.  This  structure  provides  a  two-tier  scope — a  lower  tier  of  molecular,  task-oriented 
services  that  are  intended  for  widespread  as-is  reuse  and  orchestrating  services  that  must  be  tai¬ 
lored  for  reuse.  Orchestrating  services  satisfy  a  defined  scope  much  as  a  product  line  restricts 
scope.  Scoping  of  service  applications  addresses  some  of  the  design  risk  of  unbounded  reuse.  In¬ 
herent  in  product  lines  is  restriction  of  atomic  services. 

Klaus  Turowski  of  the  University  of  Augsburg,  along  with  others  in  the  German  information  sys¬ 
tems  community,  has  identified  seven  levels  for  specifying  components  within  an  information 
systems  application  [Fellner  2000].  These  components  range  in  complexity  from  blocks  of  code, 
modules,  classes,  objects,  macro/templates,  abstracts,  data  types,  to  component.  The  framework 
distinguishes  among  these  by  reuse  (e.g.,  platform  dependency  or  inter-component  dependency), 
interface  standards,  interoperability,  extent  of  deployment,  marketability,  and  other  factors.  This 
work  has  been  extended  to  cover  real-time  service  selection  in  component-based  architectures 
[Skroch  2007].  Adding  services  to  the  classification  framework,  and  possibly  components  and 
services  of  different  granularities,  could  also  support  a  service-to-component  core  asset  compari¬ 
son. 

The  group  discussed  the  perceived  differences  between  reusable  services  and  components  in  a 
product  line.  Components  generally  operate  within  a  context  defined  by  the  architecture.  The 
component  interface  defines  that  context,  and  any  component  user  must  satisfy  the  terms  of  use. 
Services,  especially  those  that  Jaejoon  Lee’s  paper  refers  to  as  molecular,  make  no  assumptions 
about  context  of  use.  While  reusable  services  are  intended  for  use  in  different  contexts,  a  compo¬ 
nent  could  similarly  be  built  without  any  assumptions  regarding  context.  A  research  area  could  be 
established  in  order  to  determine  the  additional  context  information  or  assumptions  that  must  be 
stored  and/or  communicated.  One  proposed  solution  is  an  information  broker  that  makes  services 
available  through  user  registration  with  the  broker.  This  approach  could  manage  context  between 
a  service  or  component  and  its  respective  users. 

4.4  WHAT  ARE  THE  ARCHITECTURAL  ASPECTS  OF  SPLs  VERSUS  SOA? 

The  discussion  contrasted  differences  in  architecture  practices  between  those  used  with  product 
lines  and  those  used  with  SOA.  While  both  share  the  need  to  define  architecture  context,  struc¬ 
ture,  and  compositional  rules,  many  of  the  participants  perceive  a  significant  contrast  between 
SOA  and  product  line  architecture  practices  as  summarized  in  the  following  table. 
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Table  1:  Differences  Between  Architecture  Practices  for  SO/4  and  Product  Lines 


SOA  Architecture  Practices 

Product  Line  Architecture  Practices 

Architecture  characterized  as  autonomous,  de¬ 
centralized 

Architecture  characterized  as  centralized,  static 

Business  processes  examined  and  modeled 

Architectures  concentrate  on  views  and  view¬ 
points  for  architecture  descriptions 

Rules  easily  changed 

Compositional  rules  predefined 

Variability  only  within  services  or  possibly 
within  processes 

Variability  within  structure  and  components 

Architecture  defined  by  platfonn  (e.g.,  enter¬ 
prise  service  bus) 

Architecture  defines  platfonn 

Role  of  SOA  unclear  with  respect  to  quality 
attributes 

Architecture  guarantees  quality  attributes 

A  final  aspect  of  the  discussion  contrasted  the  perceived  “simplicity”  of  SOA  systems.  Integrating 
independent  services,  the  SOA  protocols  (web-based  or  others)  and  underlying  platform  may  ad¬ 
dress  many  architectural  issues  that  are  open  design  problems  for  a  product  line  architecture.  The 
SOA  developer  in  this  view  is  the  service  developer/provider  of  interfaces  with  concerns  separate 
from  those  of  the  integration  environment  using  services  through  published  interfaces. 

4.5  WHAT  IS  THE  SCOPE  OF  A  SYSTEM  IN  THE  CONTEXT  OF  SERVICES? 

This  part  of  the  discussion  focused  on  the  meaning  of  a  service  product  line.  Suppose  services  are 
offered  as  static  services  for  others.  The  offered  services  describe  the  scope  of  a  product  line,  de¬ 
fined  by  the  functions  offered,  and  vary  according  to  nonfunctional,  quality  attributes  such  as  se¬ 
curity,  memory/processor  performance,  or  availability.  Selection  among  services  may  occur  at 
runtime  based  on  quality  attributes  offered  by  services  performing  the  same  function. 

Many  organizations  control  large  numbers  of  services  to  support  internal  processes.  Services  may 
be  shared  across  groups  within  the  organization,  with  designated  partners,  or  on  the  open  market. 
The  granularity  of  use  within  a  product  line  of  services  may  be  at  the  level  of  just  a  single  service 
inside  one  product  line — basically  one  feature  where  SOA  is  not  a  factor — or  entire  applications 
may  be  fashioned  by  utilizing  services  from  across  the  service  product  line.  Service  orientation  in 
the  latter  context  becomes  a  variability  mechanism. 

The  service  product  line  could  itself  be  used  across  multiple  product  lines.  Services  might  not 
even  be  bound  within  a  domain  of  a  particular  product  line.  Microsoft  offers  the  Workflow  Foun¬ 
dation  to  rapidly  build  activity-based  applications.  These  are  generally  service  oriented  and  may 
in  turn  use  BizTalk  services  to  perform  a  variety  of  identity  and  connection  management  opera¬ 
tions.  Other  examples  might  exist  and  enrich  the  understanding  of  product  line  and  scope  of  ser¬ 
vice  applicability. 
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5  Workshop  Outcomes 


The  First  Workshop  on  Service-Oriented  Architectures  and  Product  Lines  (SOAPL)  2007  made 
progress  towards  answering  the  two  questions  relating  to  the  comiections  between  SOA  and  prod¬ 
uct  lines: 

1.  Can  services  support  product  lines  using  an  SOA? 

2.  How  can  use  of  product  line  practices  support  services  and  SOAs? 

The  accepted  papers,  located  in  Appendices  A-E,  provided  a  basis  for  identifying  key  issues  relat¬ 
ing  to  the  workshop  theme  “Service-Oriented  Architectures  and  Product  Lines  -  What  Is  the  Con¬ 
nection?”  Along  with  the  workshop  presentations  described  in  Section  3,  the  papers  helped  estab¬ 
lish  topics  for  additional  discussion  at  the  workshop,  as  described  in  Section  4. 

A  look  at  the  comparison  of  software  product  line  and  service-oriented  modeling  methods  identi¬ 
fied  key  issues  in 

•  the  perceived  static  focus  of  software  product  lines  versus  the  dynamic  focus  of  service- 
oriented  computing 

•  variability  modeling  in  services 

•  the  creation  of  standards  for  software  product  lines  similar  to  those  being  developed  for 
services 

Participants  addressed  features  and  variability  issues  by  examining  how  software  product  line 
practices  might  support  the  management  of  variability  in  service-oriented  applications.  For  exam¬ 
ple,  could  feature  modeling  be  used  to  identify  the  variability  points  in  the  invocation  of  compos¬ 
ite  web  services?  Could  this  initial  knowledge  base  be  used  to  evaluate  the  different  mechanisms 
for  implementing  variability  in  composite  web  services  and  to  identify  factors  that  affect  the  se¬ 
lection  of  such  variability  mechanisms? 

Application  examples  addressed  the  challenges  of  dynamically  managing  services  in  an  SOA- 
based  system: 

•  how  product  line  engineering  concepts  can  be  used  to  identify  and  specify  reusable  ser¬ 
vices — based  on  features 

•  how  a  service-oriented  approach  can  be  used  to  combine  different  products  from  different 
product  lines  into  a  third  product  line 

Additional  discussions  covered  the  use  of  services  within  a  product  line  architecture,  developing  a 
service  as  a  product  line,  the  dynamic  aspects  of  SOA  versus  product  lines,  reusable  services,  the 
perceived  differences  between  reusable  services  and  components  in  a  product  line,  architectural 
aspects  of  software  product  lines  versus  service-oriented  computing,  and  the  meaning  of  a  service 
product  line. 
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The  participants  felt  the  goals  of  the  workshop  were  addressed.  The  workshop  offered  an  early 
glimpse  at  how  the  SPL  community  looks  at  SOA.  It  examined  tools  and  techniques  currently  in 
progress  and  generated  a  list  of  open  questions  for  future  research  directions.  Most  importantly, 
the  workshop  provided  the  ability  to  network  with  others  working  on  the  same  issues. 

Several  participants  discussed  follow-on  work  that  should  be  monitored.  Mikko  Raatikainen  plans 
to  work  on  “how  to  build  configurable  services”  (i.e.,  understanding  issues,  the  modeling  of  be¬ 
haviors,  tool  support,  and  dynamic  aspects).  Jaejoon  Lee  will  continue  implementation  of  the 
model  and  complete  the  current  work  described  in  the  paper  he  presented.  He  will  also  start  ex¬ 
ploring  platform  issues  (such  as  .net).  Christian  Kastner  plans  to  implement  the  web  portal  of 
portlets  example  and  look  at  how  to  dynamically  consume  configured  products  from  the  product 
line. 

The  workshop  participants  felt  that  this  workshop  should  be  followed  up  with  a  second  SOAPL 
workshop  at  the  12th  International  Software  Product  Line  Conference  (SPLC  2008),  Limerick, 
Ireland.  Suggested  changes  for  this  workshop  are 

•  Include  SOA  representations.  The  participants  at  this  workshop  primarily  represented  soft¬ 
ware  product  lines.  The  second  workshop  should  include  experts  in  SOA  to  balance  the  dis¬ 
cussions. 

•  Include  a  keynote  speaker  to  open  up  the  workshop. 

•  Invite  and  include  more  experience  reports.  The  workshop  papers  should  focus  on  experi¬ 
ence  reports  rather  than  research  or  simply  the  connection  between  service-oriented  architec¬ 
tures  and  product  lines. 

•  Invite  a  product  line  architect  to  address  dynamic  versus  static  issues. 
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ABSTRACT 

Service- Oi ien ted  Architectures  (SOA) 
and  Software  Product  Lines  are  two  con¬ 
cepts  that  currently  get  a  lot  of  attention  in 
research  and  practice.  Both  promise  to  make 
possible  the  development  of  flexible,  cost- 
effective  software  systems  and  to  support 
high  levels  of  reuse.  But  at  the  same  time 
they  are  quite  different  from  one  another: 
while  Software  Product  Lines  focus  on  one 
producer  alone  developing  a  set  of  systems 
based  on  a  common  platform  (often  in  the 
embedded  systems-domain),  most  propo¬ 
nents  of  SOA  propose  systems  consisting  of 
loosely  coupled  services  or  company-wide 
infrastructures  including  a  variety  of  sys¬ 
tems  that  are  loosely  coupled  using  services. 
In  any  case,  the  services  are  usually  devel¬ 
oped  by  various  companies.  The  focus  of  this 
paper  is  the  systematic  comparison  of  these 
concepts  and  an  outlook  on  how  Enterprise 
Component  Platforms  could  be  created  by 
combining  SOA  and  Software  Product  Lines. 

A.1  INTRODUCTION 

The  focus  of  this  paper  is  the  systematic 
comparison  of  Software  Product  Lines  and 
SOA.  Specifically,  the  goal  is  to  analyze 
both  concepts  with  two  questions  in  mind: 

1)  Can  web  services  support  product  lines 
using  a  service-oriented  architecture? 


2)  How  can  use  of  product  line  practices 
support  web  services  and  service-oriented 
architectures?  Therefore,  we  briefly  describe 
Software  Product  Lines  and  SOA  in  Section 
A. 2  before  comparing  them  using  defined 
criteria  in  Section  A. 3.  Our  conclusion  in 
Section  A. 4  recapitulates  the  findings,  link¬ 
ing  them  with  the  concept  of  Enterprise 
Component  Platforms.  Also,  an  outlook  on 
further  research  that  is  necessary  is  given. 

A.2  BRIEF  PRESENTATION  OF  THE 
CONCEPTS 

A.2.1  SOA 

“SOA  is  a  conceptual  business  architecture 
where  business  functionality,  or  application 
logic,  is  made  available  to  SOA  users,  or 
consumers,  as  shared,  reusable  services  on 
an  IT  network.  ‘Services’  in  an  SOA  are 
modules  of  business  or  application  function¬ 
ality  with  exposed  interfaces,  and  are  in¬ 
voked  by  messages”  [1],  Service-oriented 
development  essentially  integrates  disparate 
heterogeneous  software  services  from  a 
range  of  providers  [2],  Thus,  an  SOA  is  a 
means  of  designing  software  systems  to  pro¬ 
vide  services  to  either  end  user  applications 
or  other  services  through  published  and  dis¬ 
coverable  interfaces.  There  are  several  guid¬ 
ing  principles  that  define  the  ground  rules 
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for  development,  maintenance,  and  usage  of 
the  SOA.  The  guiding  principles  cover  [3]: 

•  Reuse,  granularity,  modularity,  compos- 
ability,  componentization,  and  interop¬ 
erability, 

•  Compliance  to  standards  (both  common 
and  industry-specific), 

•  Service  identification  and  categoriza¬ 
tion,  provisioning  and  delivery,  and 
monitoring  and  tracking. 

The  following  specific  architectural  prin¬ 
ciples  for  design  and  service  definition  focus 
on  specific  themes  that  influence  the  intrin¬ 
sic  behavior  of  a  system  and  the  style  of  its 
design.  They  are  derived  from  the  guiding 
principles  and  cover  [3]: 

•  Service  encapsulation  -  Accessing  func¬ 
tionality  through  some  well-defined  in¬ 
terface,  the  application  being  seen  as  a 
black  box  to  the  user 

•  Service  loose  coupling  -  Services  main¬ 
tain  a  relationship  that  minimizes  de¬ 
pendencies  and  only  requires  that  they 
maintain  an  awareness  of  each  other. 

•  Service  contract  -  Services  adhere  to  a 
communications  agreement,  as  defined 
collectively  by  one  or  more  service  de¬ 
scription  documents. 

•  Service  abstraction  -  Beyond  what  is 
described  in  the  service  contract,  ser¬ 
vices  hide  logic  from  the  outside  world. 

•  Service  reusability  -  Logic  is  divided 
into  services  with  the  intention  of  pro¬ 
moting  reuse. 

•  Service  composability  -  Collections  of 
services  can  be  coordinated  and  assem¬ 
bled  to  form  composite  services. 

•  Service  autonomy  -  Services  have  con¬ 
trol  over  the  logic  they  encapsulate. 

•  Service  statelessness  -  Services  mini¬ 
mize  retaining  infonnation  specific  to 
an  activity. 

•  Service  discoverability  -  Services  are 
designed  to  be  outwardly  descriptive  so 
that  they  can  be  found  and  assessed  via 
available  discovery  mechanisms. 


While  many  early  publications  promote 
SOA  as  some  kind  of  silver  bullet  for  build¬ 
ing  flexible  applications  and  for  integrating 
different  applications,  newer  publications 
point  out  the  problems  resulting  from  this 
architectural  paradigm  and  Web  Services  as 
the  most  prominent  way  of  implementing  an 
SOA(e.g.,  [5],  Chapter  4). 

A.2.2  Software  Product  Lines 

Exploiting  commonalities  between  dif¬ 
ferent  systems  is  at  the  heart  of  Software 
Product  Line  Engineering.  Therefore,  differ¬ 
ent  products  of  one  domain  (also  referred  to 
as  problem  space  or  application  range,  e.g., 
operating  systems  for  mobile  telephones  or 
software  support  of  the  sales  department)  are 
viewed  as  a  family  and  not  as  single  prod¬ 
ucts.  According  to  the  SEI  at  Carnegie  Mel¬ 
lon  University,  Software  Product  Lines  are 
defined  as  “set  of  software-intensive  sys¬ 
tems  sharing  a  common,  managed  set  of 
features  that  satisfy  the  specific  needs  of  a 
particular  market  segment  or  mission  and 
that  are  developed  from  a  common  set  of 
core  assets  in  a  prescribed  way”  (cf.  [6],  p. 
5).  The  main  elements  of  a  Software  Product 
Line  are  the  product  line  architecture  and  the 
individual  products  which  are  part  of  the 
product  line.  The  product  line  architecture 
describes  the  individual  products,  their 
common  components  and  the  differences 
between  the  products  of  the  family  (cf.  [7]). 
These  commonalities  and  differences  are 
described  using  the  core  concept  in  Software 
Product  Line  Engineering:  variability.  Vari¬ 
ability  describes  the  variations  in  (functional 
as  well  as  non-functional)  features  along  the 
product  line:  features  are  either  a  commonal¬ 
ity  or  a  variation  [8]. 

Different  process  models  exist  for  the  devel¬ 
opment  process  of  product  lines,  e.g.,  those 
described  in  [9],  [10]  or  [1 1].  Common  to 
them  is  that  the  product  line  development 
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process  is  modeled  along  the  structure  of  a 
product  line.  Just  as  the  product  line  consists 
of  product  line  architecture  and  product  line 
members,  the  development  process  also  con¬ 
sists  of  the  process  of  the  development  of 
the  product  line  architecture  and  the  devel¬ 
opment  process  of  product  line  members. 
The  development  of  the  product  line  archi¬ 
tecture  is  called  domain  engineering  and  the 
development  of  the  product  line  members  is 
called  application  engineering.  Preceding 
both  is  the  activity  called  scoping,  that  is  the 
process  during  which  it  is  determined  what 
to  develop,  i.e.,  which  products  will  be  part 
of  the  product  line  and  what  the  commonal¬ 
ities  and  variabilities  will  be.  Since  both 
domain  engineering  and  application  engi¬ 
neering  encompass  analysis,  design,  imple¬ 
mentation  and  testing,  the  resulting  model  is 
also  called  the  two  life-cycle  model. 

A.3  COMPARISON  OF  THE 
CONCEPTS 

Having  presented  Software  Product  Lines 
and  Service-Oriented  Architecture,  we  will 
now  compare  these  concepts  and  investigate 
the  commonalities  and  differences  between 
the  concepts.  To  facilitate  the  comparison, 
we  use  the  following  criteria: 

•  Goal:  What  exactly  is  the  concept  trying 
to  achieve? 

•  Defining  features:  What  are  the  charac¬ 
teristics  of  the  concept  that  are  at  its 
heart? 

•  Technical  methods  and  elements:  Which 
Software  Engineering  methods  and  ele¬ 
ments  are  used  to  develop  systems  in 
this  concept? 

•  Organizational  methods  and  elements: 
How  is  software  development  organized 
according  to  this  concept  and  which  are 
the  key  steps  in  the  development  proc¬ 
ess? 


•  Field  of  application:  In  what  kinds  of 
software  is  this  concept  primarily  ap¬ 
plied? 

•  Reuse  methods  and  entities:  All  three 
concepts  have  reuse  in  one  way  or  an¬ 
other  as  their  goal,  but  the  methods  and 
entities  that  are  reused  differ  substan¬ 
tially. 

•  Level  of  Abstraction:  Which  is  the  pri¬ 
mary  unit  of  analysis  for  reuse?  Not 
only  methods  and  entities,  even  the 
level  of  abstraction  differs  significantly. 

•  Examples:  To  illustrate  the  concepts, 
some  examples  for  real-world  applica¬ 
tion  of  each  concept  are  presented  here. 

Table  A-l  provides  an  overview  of  the 
comparison  using  these  criteria,  whereas  the 
in-depth  comparison  follows  in  the  remain¬ 
der  of  this  section. 

The  primary  goal  of  Software  Product 
Lines  is  to  promote  reuse  and  thereby  realize 
gains  in  productivity,  software  quality  and 
time  to  market.  More  specifically,  exploiting 
the  commonalities  between  related  products 
is  the  actual  goal.  To  achieve  this,  rather 
extensive  analyzing  and  planning  processes 
for  the  whole  set  of  systems  to  be  developed 
are  performed.  After  that,  the  common  archi¬ 
tecture  and  the  so-called  core  assets  are  de¬ 
veloped  in  a  generic  way  (domain  engineer¬ 
ing),  before  the  systems  belonging  to  the 
product  line  are  developed  (application  en¬ 
gineering).  Neither  architecture  nor  core 
assets  are  planned  to  be  reused  outside  the 
Software  Product  Line.  The  primary  goal 
behind  SOA  is  to  promote  flexibility  in  in¬ 
formation  systems/corporate  information 
systems  landscapes:  today  large  enterprise 
application  packages  and  tight  coupling  be¬ 
tween  different  packages  and  legacy  systems 
are  prevalent,  leading  to  problems  whenever 
a  new  system  is  introduced  or  business 
needs  require  changes  in  existing  systems 
and/or  their  interfaces.  SOA  seeks  to  change 
this  by  developing  rather  small  services 
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Table  A-1:  Comparison  of  the  Concepts 


Criteria 

Software  Product  Lines 

Service-Oriented  Architecture 

Goal 

Planned  exploitation  of  commonalities  within  related 
systems  ->  reuse 

Use  of  services  of  fine  granularity  within  (enterprise) 
system  landscapes  ->  flexibility 

Defining 

features 

Variability;  Family  of  related  systems  based  on 
common  architecture 

No  common  architecture,  services  are  encapsulated 
and  loosely  coupled 

Technical 
methods  and 
elements 

Variation  points  and  mechanisms,  scoping,  applica¬ 
tion  engineering,  domain  engineering 

Reliance  on  generally  accepted  standards,  additional 
service  registration  and  authentication  services 

Organizational 
methods  and 
elements 

Two  life-cycle  models:  first  domain  engineering  to 
develop  the  assets  to  be  reused,  then  application 
engineering  to  derive  the  actual  systems 

Development  as  well  as  hosting  of  the  services  can  be 
distributed,  only  the  light-weight  interface  and  some 
additional  services  (registry,  authentication...)  are  pro¬ 
vided 

Reuse  methods 
and  entities 

Logical  reuse  of  all  kinds  of  assets  (components, 
test  cases,  analysis  &  design  models),  but  only 
within  the  product  line 

Services  are  physically  reused,  potentially  by  anyone, 
and  can  be  combined  with  other  services  into  more 
complex  services 

Level  of 
abstraction 

Primarily  family  of  systems  and  secondarily  systems 
within  the  family 

Single  services  (atomic  or  composed  of  services) 

Examples 

Nokia  cell  phones,  Cummins  diesel  engines 

Telecommunications  provider 

(potentially  totally  independent  from  each 
other).  These  are  published  in  a  registry 
(e.g.,  using  the  Standards  WSDL  and  UDDI) 
and  can  then  be  used  by  anyone  within  a 
company  or  even  world-wide  (the  so-called 
service  consumer).  As  Dietzsch  [12]  points 
out,  this  kind  of  reuse  is  physical  rather  than 
logical:  the  same  entity  provides  the  service, 
not  a  copy  of  the  entity  (a  reused  component 
is  a  copy  of  the  original  component  used  in 
another  piece  of  software,  the  service  is  re¬ 
used  by  sending  a  request  to  the  very  same 
service  over  the  network/Internet).  Such  a 
service  can  be  part  of  a  system,  stand  alone 
or  be  a  connector  between  two  independent 
systems.  Additionally,  a  service  can  be 
atomic  or  combine  several  services  (compo¬ 
sition  of  services). 

Software  Product  Lines  are  mainly  fo¬ 
cused  on  internal  reuse  of  components  in 
another  product,  while  the  focus  of  Service- 
Oriented  Architecture  is  the  reuse  of  compo¬ 


nent-based  software  on  a  larger  scale.  The 
creation  of  SOA-compliant  component- 
based  software  (e.g.,  Modules  or  Compo¬ 
nents  in  Enterprise  Resource  Planning  Soft¬ 
ware  like  SAP)  seems  to  become  a  popular 
business  model  for  companies,  e.g.,  sub¬ 
suppliers  to  SAP’s  ERP  system,  that  mainly 
focus  on  the  creation  of  reusable  compo¬ 
nent-based  software  but  also  for  bigger 
companies,  enabling  them  to  sell  SOA- 
compliant  component-based  software  that 
was  developed  in-house.  Since  this  will 
probably  lead  to  customers  combining  ser¬ 
vices  from  different  suppliers,  one  could 
also  argue  that  reuse  will  actually  become 
less  common:  instead  of  a  few  large  compa¬ 
nies  developing  ERP  systems  and  customers 
buying  the  whole  package,  many  other  com¬ 
panies  can  offer  specialized  services  replac¬ 
ing  the  service  included  in  the  package.  This 
does  increase  the  choice  for  the  customers, 
but  not  the  level  of  software  reuse. 
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The  defining  feature  of  the  concept  of 
Software  Product  Lines  is  variability  (and 
vice  versa  commonality)  as  defined  by  the 
common  and  application-specific  parts  of 
the  systems  that  are  part  of  the  Software 
Product  Line;  this  includes  defining  a  com¬ 
mon  architecture.  This  common  architecture 
is  lacking  SOA;  one  could  even  say  that  the 
lack  of  a  common  architecture  (since  the 
service  could  be  used  by  anyone  as  part  of 
his/her  system  with  its  specific  architecture) 
is  one  of  the  defining  features  together  with 
the  services  being  encapsulated  and  loosely 
coupled.  On  the  other  hand,  some  of  the  as¬ 
pects  usually  included  in  an  architecture  still 
have  to  be  specified  for  services  in  order  for 
them  to  be  able  to  work  together,  e.g.,  mes¬ 
saging  (cf.  [5]). 

The  technical  methods  and  elements 

that  are  typical  for  the  concepts  are  addi¬ 
tional  criteria  we  used:  for  Software  Product 
Lines,  variation  points  and  variation  mecha¬ 
nisms  and  the  distinction  between  scoping, 
domain  engineering  and  application  engi¬ 
neering  are  the  defining  technical  methods 
and  elements.  While  variation  points  and 
variation  mechanisms  provide  the  opportu¬ 
nity  to  efficiently  handle  the  differences  be¬ 
tween  the  members  of  a  product  line,  scop¬ 
ing,  domain  engineering  and  application 
engineering  are  distinct  phases  in  the  devel¬ 
opment  process  where  special  methods  for 
Software  Product  Line  Engineering  are  used 
(see  for  example  [6]  for  details).  Since  SOA 
is  a  concept  that  is  rather  independent  of  the 
development  platform/language  to  be 
used,  the  reliance  on  the  architectural  prin¬ 
ciples  mentioned  in  Section  A.2.1  need  to  be 
mentioned  here.  Additionally,  standards  such 
as  UDDI  and  WSDL  are  important  and  ab¬ 
solutely  necessary  elements  of  SOA. 

Organizational  methods  and  elements: 

unlike  the  technical  methods  and  elements, 
the  organizational  methods  and  elements 


define  the  way  software  development  is  or¬ 
ganized.  For  Software  Product  Lines,  the 
key  question  here  is  how  domain  engineer¬ 
ing  and  application  engineering  are  organ¬ 
ized:  basically,  they  are  separate  develop¬ 
ment  cycles  with  application  engineering 
depending  on  the  results  of  domain  engi¬ 
neering.  This  could,  for  example,  lead  to 
separate  teams  responsible  for  domain  and 
application  engineering.  Another  possibility 
would  include  a  separate  team  for  domain 
engineering,  with  a  member  of  this  team 
being  part  of  each  application  engineering 
team.  For  an  in-depth  discussion  of  possible 
ways  to  organize  Software  Product  Line 
Engineering  see  [13],  but  basically  all  possi¬ 
bilities  have  their  own  advantages  and  dis¬ 
advantages  and  their  suitability  depends  on 
the  organization  of  the  company  as  a  whole. 
For  SOA,  it  is  more  difficult  to  make  any 
statements  concerning  the  organization  since 
every  service  could  be  developed  independ¬ 
ently  of  all  other  services.  But  this  implies  a 
decentralized  organization  with  no  central¬ 
ized  coordinating  unit,  since  there  is  no 
common  architecture  behind.  For  a  company 
reorganizing  their  own  infrastructure  in  an 
SOA-based  way,  there  probably  will  be  such 
a  centralized  unit,  but  they  might  very  well 
use  services  that  have  been  provided  by 
third  parties  that  were  not  coordinated  by 
this  unit.  The  reliance  on  additional  services 
such  as  a  service  registry  and  services  for 
identification  or  authentication  implies  sepa¬ 
rate  centralized  organizational  units  provid¬ 
ing  these  services  to  all  other  services. 

The  reuse  methods  and  entities  differ 
quite  substantially:  in  a  Software  Product 
Line,  all  kinds  of  assets  are  reused,  not  only 
code,  but  also  specifications,  models  (e.g.,  in 
UML),  test  cases  and  (end  user)  documenta¬ 
tion,  but  only  within  the  Software  Product 
Line.  In  an  SOA,  the  services  are  the  main 
reuse  entity,  and  interestingly,  the  services 
are  physically  and  not  only  logically  reused. 
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Thereby,  logical  reuse  is  present,  if  a  com¬ 
ponent  is  replicated  and  delivered  by  the 
manufacturer  to  the  application  developer. 
By  physical  reuse  however,  the  service  is 
invoked  by  remote  call  on  demand  [12].  In 
this  case  the  service,  e.g.,  a  single-sign-on 
Web  Service,  is  hosted  by  the  manufacturer 
of  the  software. 

Taking  organizational  methods  and  ele¬ 
ments  on  the  one  hand  and  the  reuse  meth¬ 
ods  and  elements  on  the  other  hand,  one  gets 
the  matrix  shown  in  Table  A-2. 


Table  A-2:  Organizational  Level  of  Reuse 


Phase  within 
the  two- 
lifecycle  model 

Software 

Product 

Lines 

Service-Oriented 

Architecture 

Development 
for  reuse 

within 

organiza¬ 

tion 

within  organization 
/  outside  the 
organization 

Development 
with  reuse 

within 

organiza¬ 

tion 

outside  the 
organization 

Closely  related  to  the  reuse  entity  is  the  level 
of  abstraction:  all  considerations  for  a 
Software  Product  Line  are  based  on  the 
product  line  as  a  unit  of  analysis,  all  deci¬ 
sions  on  another  level  (product,  component 
or  even  function)  are  derived  from  the  utility 
on  the  product  line  level.  As  the  name  Ser¬ 
vice-Oriented  Architecture  already  implies, 
single  services  are  the  main  unit  of  analysis 
in  this  concept,  since  a  service  can  theoreti¬ 
cally  stand  alone. 

Cummins  diesel  engines  and  Nokia  cell 
phones  are  just  two  examples  for  the  appli¬ 
cation  taken  from  the  Software  Product  Line 
Hall  of  Fame  [14].  One  example  of  using 
SOA  in  order  to  streamline  business  proc¬ 
esses  and  to  integrate  various  applications  is 
presented  in  [15],  where  a  “large  telecom¬ 
munication  wholesaler,  supplying  its  ser¬ 
vices  to  more  than  150  different  service  re¬ 


tailers,  enhanced  the  process  integration 
capabilities  of  its  core  order  management 
system  through  wide-spread  use  of  SOA, 
business  process  choreography  and  Web 
services  concepts”  [15]. 

A.4  CONCLUSION 

The  goal  of  this  paper  was  the  systematic 
comparison  of  Software  Product  Lines  and 
Service-Oriented  Architectures.  The  com¬ 
parison  shows  that  the  two  concepts  share  a 
number  of  characteristics,  but  differ  signifi¬ 
cantly  in  other  characteristics.  And  where 
they  differ,  they  sometimes  actually  com¬ 
plement  each  other,  e.g.,  while  Software 
Product  Lines  do  not  focus  on  components 
being  marketable  or  developed  in  different 
organizations,  this  is  not  explicitly  excluded. 
At  the  same  time,  many  proponents  of  SOA 
argue  that  SOA  will  lead  to  companies  not 
purchasing  licenses  for  large  application 
packages  but  instead  using  services  and  pay¬ 
ing  per  use  of  the  services,  thereby  combin¬ 
ing  best-of-breed  services  from  multiple 
providers.  Designing  Software  Product 
Lines  based  on  a  Service-Oriented  Architec¬ 
ture  with  the  possibility  of  replacing  or  ex¬ 
tending  existing  functionality  by  services 
offered  by  third-party  providers  opens  a  path 
towards  Enterprise  Component  Platforms 
that  we  find  very  promising.  This  leads  to 
new  research  questions,  e.g.,  on  pricing  of 
services  and  the  platform,  security  and 
safety  of  the  resulting  systems,  but  also  on 
business  models  for  Enterprise  Component 
Platforms.  The  large  business  software  com¬ 
panies,  i.e.,  SAP,  Oracle,  IBM  and  Microsoft 
have  already  invested  large  amounts  of 
money  and  effort  into  the  transition  of  their 
application  packages  into  services,  while 
trying  to  maintain  control  over  the  resulting 
platform  and  trying  to  create  a  network  of 
partners  supporting  the  platform.  SAP  for 
example  uses  the  term  business  ecosystem 
(cf.  for  example  [16]  and  [17]  for  SAP’s 
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strategy  or  [18]  and  [19]  for  a  more  theoreti¬ 
cal  viewpoint). 
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ABSTRACT 

The  combination  of  Software  Product 
Lines  (SPLs)  and  Service-Oriented  Architec¬ 
tures  (SO As)  development  practices  is  ex¬ 
pected  to  become  a  new  development  para¬ 
digm  maximizing  reuse  and  business 
integration.  However,  multiple  issues  must 
be  still  addressed  in  order  to  clarify  the 
connections  between  both  fields.  One  of  the 
key  questions  to  answer  is  how  SPL  prac¬ 
tices  can  be  used  to  support  service-oriented 
applications.  In  this  context,  identifying  and 
managing  the  points  of  variability  in  com¬ 
posite  Web  services  emerges  as  an  inevita¬ 
ble  step  for  making  possible  such  integra¬ 
tion.  In  this  position  paper  we  give  a  first 
step  toward  such  direction  by  introducing  a 
comprehensible  overview  of  the  main  vari¬ 
ability >  points  in  Web  service  flows. 

B.1  INTRODUCTION 

Software  Product  Lines  (SPLs)  [8]  and 
Service-Oriented  Architectures  (SO As)  [18] 
approaches  to  software  development  pursue 
different  goals  from  a  common  perspective: 
software  reuse.  On  the  one  hand,  SPLs  focus 
on  managing  commonalities  and  variabilities 
among  a  set  of  related  software  systems.  On 
the  other  hand,  SOAs  enable  assembly,  or¬ 
chestration  and  maintenance  of  service- 
based  solutions  implementing  business 
processes. 


Contributions  about  the  connections  be¬ 
tween  both  development  approaches,  SPLs 
and  SOAs,  are  starting  to  emerge  in  the  SPL 
community  [22].  However,  multiple  issues 
must  be  still  addressed  for  studying  how 
SPL  practices  could  support  the  develop¬ 
ment  of  service-oriented  systems.  In  this 
context,  a  relevant  issue  to  be  analyzed  is 
managing  variations  for  specific  customers 
or  market  segments  in  SOA. 

Service-oriented  applications  are  not  tied 
to  a  specific  technology.  However,  the  most 
common  implementations  of  SOA-based 
systems  use  Web  services  as  a  suitable  inte¬ 
gration  technology.  A  Web  service  is  a 
software  system  designed  to  support  inter¬ 
operable  machine-to-machine  interaction 
over  a  network  using  Web  standards  proto¬ 
cols  [2],  The  main  goal  is  to  achieve  inter¬ 
operability  among  applications  in  a  language 
and  platform  independent  manner.  However, 
the  real  strength  of  Web  services  is  obtained 
when  combining  them  and  orchestrating 
them  in  order  to  deliver  value-added  ser¬ 
vices.  In  this  context,  Web  Service  Flows 
(WS-flows)  are  a  common  way  of  imple¬ 
menting  composite  Web  services  in  SOA. 
WS-flows  are  composite  Web  services  im¬ 
plemented  using  a  process-based  approach. 
Roughly  speaking,  a  WS-flow  process  de¬ 
fines  an  executable  business  process  in 
which  participants  are  Web  services. 


This  work  has  been  partially  supported  by  the  European  Commission  (FEDER)  and  Spanish  Government  under  CICYT 
project  Web-Factories  (TTN2006-00472). 
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Research  in  the  field  of  variability  in 
conventional  Web  services  [12,  16,  19]  and 
process  workflow  [7,  10,  11,  15,  20]  is 
merely  addressed  in  the  literature.  In  [13]  a 
high  level  classification  of  approaches  to 
WS-flow  adaptability  is  presented.  A  more 
technological  classification  of  WS-flow 
variability  points  in  service  invocation  is 
introduced  by  IBM  staff  in  [9].  However,  an 
explicit  classification  of  the  main  variability 
points  in  WS-flow  is  still  missed. 

In  this  paper  we  give  a  first  step  toward  a 
proposal  for  managing  variability  in  WS- 
flow  in  the  context  of  SPLs  and  SOAs.  In 
particular,  we  first  introduce  WS-flow  and 
BPEL.  Secondly,  we  describe  and  classify 
the  main  variability  points  in  WS-flow.  The 
goal  is  to  provide  the  starting  point  for  a 
base  of  knowledge  about  variability  in  WS- 
flows  that  can  be  later  used  for  both:  1) 
evaluating  the  different  mechanisms  for  im¬ 
plementing  variability  in  WS-flow  and  2) 
identifying  factors  that  affect  the  selection  of 
such  variability  mechanisms. 

The  remainder  of  this  paper  is  organized 
as  follows:  In  Section  B.2  WS-flows  and 
BPEL  are  introduced.  The  main  variability 
points  identified  in  WS-flows  are  described 
in  Section  B.3.  Finally,  we  summarize  our 
main  conclusions  and  describe  our  future 
work  in  Section  B.4. 

B.2  WEB  SERVICE  FLOWS 

A  Web  Service  Flow  (WS-flow)  is  a  com¬ 
posite  Web  service  implemented  using  a 
process-based  approach  [13].  Similar  to 
conventional  process  workflow,  WS-flows 
specify  a  set  of  tasks  which  are  executed  by 
the  participants  of  a  process.  Additionally,  a 
WS-flow  defines  the  execution  order  of 
tasks,  the  data  exchange  among  the  partici¬ 
pants  and  the  business  rules.  In  contrast  with 
traditional  workflows,  the  main  characteris¬ 


tic  of  a  WS-flow  is  that  it  works  mainly  with 
a  single  type  of  participant:  Web  services. 
Figure  B-l  depicts  an  example  of  a  WS-flow 
of  a  travel  agency  for  travel  arrangement.  The 
WS-flow  invokes  the  Web  services  of  differ¬ 
ent  airlines,  car  rental  companies,  and  hotels 
offering  to  the  customer  a  value-added  ser¬ 
vice  for  travel  reservation. 

There  exist  multiple  proposed  languages 
for  defining  WS-flows  such  as  WSCI  [21], 
BPML  [4]  or  BPEL  [14],  However,  the  Busi¬ 
ness  Process  Execution  Language  (BPEL)  is 
recognized  as  de  facto  standard  in  this  area. 
BPEL  introduces  basic  and  structured  activi¬ 
ties,  control  structures  such  as  loops  and  con¬ 
ditional  branches,  synchronous  and  asyn¬ 
chronous  communication,  etc.  Although 
BPEL  processes  are  defined  in  XML  format, 
most  development  IDEs  provide  a  graphical 
notation  for  it.  Once  a  BPEL  process  is  de¬ 
fined  it  can  be  executed  in  any  BPEL- 
compliant  execution  engine  such  as  active- 
BPEL  [1],  The  execution  engine  orchestrates 
the  invocations  to  the  participant’s  Web  ser¬ 
vices  according  to  the  process  definition. 

B.3  VARIABILITY  IN  WS-FLOWS 

In  this  section  we  explore  the  main  vari¬ 
ability  points  in  WS-flow.  In  particular,  we 
focus  on  the  variability  in  the  invocation  of 
services  and  the  workflow  structure.  Vari¬ 
ability  in  other  advanced  aspects  of  services 
such  as  security  is  out  of  the  scope  of  this 
paper  because  of  space  constraints. 

B.3.1  Service  invocation 

A  service  invocation  is  an  activity  in  which 
the  workflow  invokes  another  service  and 
exchange  messages  with  it  returning  control 
back  to  the  workflow.  Figure  B-2  summa¬ 
rizes  the  main  variability  points  identified  in 
the  invocation  of  services  using  a  feature 
model.  In  particular,  we  have  identified 
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Figure  B-1:  A  Possible  WS-Flow  for  Travel  Arrangement 


Figure  B-2:  Variability  Points  in  Service  Invocation 


four  main  variability  points: 

•  Binding  Time.  The  selection  of  the  ser¬ 
vice  to  invoke  can  be  performed  either 
during  the  development  or  the  execu¬ 
tion  of  the  workflow.  In  the  first  case, 
the  service  reference  is  defined  in  de¬ 
sign-time  forcing  to  redeploy  the  work¬ 
flow  if  changes  in  the  participants  need 
to  be  done.  On  the  other  hand,  most 
flexible  approaches  propose  selecting 
participants  in  run-time  making  the  ap¬ 
plication  adaptable  to  changes  in  the 
execution  environment.  Additionally, 


partner  selection  during  run-time  can 
be  performed  either  by  the  user  or 
automatically  according  to  some  selec¬ 
tion  policies.  Figure  B-3  shows  a  pos¬ 
sible  implementation  of  run-time  auto¬ 
mated  partner  selection  using  a  so- 
called  service  registry  [3].  First,  the  in¬ 
formation  of  the  services  (e.g.,  different 
airline  Web  services)  is  registered  in  a 
service  registry.  Then,  the  workflow 
sends  a  query  to  the  registry  to  deter¬ 
mine  a  matching  service  according  to  a 
set  of  parameters  (e.g.,  a  service  with 
time  of  response  2  10s)  and  the  prede- 
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fined  selection  policies.  Finally,  the 
service  reference  obtained  as  a  result  of 
the  query  is  used  to  invoke  the  match¬ 
ing  service. 

•  Partner  Selection  Criteria.  Selection 
criteria  help  to  determine  which  of  the 
available  services  offering  the  same 
functionality  will  be  selected  for  its  in¬ 
vocation  [17].  In  this  context,  two  main 
variability  points  are  identified: 

Evaluation  Context.  Selection  criteria 
can  be  either  hard-coded  in  the  work¬ 
flow  or  delegated  to  an  external  entity. 
The  first  option  is  very  limited  since 
workflow  and  selection  criteria  are 
highly  coupled.  On  the  other  hand,  de¬ 
fining  the  selection  criteria  in  an  inde¬ 
pendent  manner  is  a  preferred  approach 
since  it  allows  managing  changes  more 
efficiently.  Figure  B-4  depicts  an  ex¬ 
ample  in  which  the  selection  criteria 
are  defined  out  of  the  scope  of  the 
workflow.  Notice  that  changes  in  the 
selection  criteria  would  be  welcome 
since  they  would  not  affect  the  work- 
flow. 

Definition  Time.  Selection  criteria  can 
be  modified  either  in  design-time  or 
run-time.  Similar  to  the  partner  selec¬ 
tion,  the  first  option  forces  the  workflow 
to  redeploy  to  respond  to  changes. 
Meanwhile,  the  second  alternative  is 
much  more  flexible  since  it  allows 


adapting  the  process  workflow  dynami¬ 
cally. 

•  Messages  Exchanged.  Messages  ex¬ 
changed  between  executable  service 
workflows  and  other  services  are  typi¬ 
cally  perfonned  using  two  different 
communication  patterns:  synchronous 
or  asynchronous.  Synchronous  re¬ 
quest/response  message  exchange  con¬ 
sists  of  sending  a  request  message  to 
the  service  and  waiting  for  it  to  re¬ 
spond.  Although  this  is  the  most  com¬ 
mon  and  natural  approach,  it  is  clearly 
not  feasible  if  the  services  require  sig¬ 
nificant  time  to  respond  since  it  blocks 
the  workflow  processing.  Hence,  when 
the  participants’  services  can  take  a 
long  time  to  respond  and  such  response 
is  not  needed  for  workflow  processing, 
an  asynchronous  pattern  is  typically 
used. 

In  the  asynchronous  model  the  com¬ 
munication  is  perfonned  between  two 
workflows,  the  so-called  service  pro¬ 
vider  and  service  requestor  or  client.  In 
this  situation,  the  client  need  not  block 
the  call.  Instead,  the  client  implements 
a  callback  interface,  and  once  the  re¬ 
sults  are  available,  the  service  provider 
simply  makes  a  callback  invocation  on 
the  client.  Figure  B-5  illustrates  an  ex¬ 
ample  of  asynchronous  message  ex¬ 
change. 
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Figure  B-3:  Service  Registry 


Figure  B-4:  Workflow-Independent  Selection  Criteria 


Figure  B-5:  Asynchronous  Model 


•  Protocols.  Multiple  protocols  can  be 
used  for  service  interactions  over  a  net¬ 
work,  i.e.,  SOAP/HTTP,  SOAP/JMS, 
XML/HTTP,  etc.  Thus,  the  selection  of 
a  suitable  set  of  protocols  for  the  com¬ 
munication  with  services  is  a  key  vari¬ 
ability  point. 

B.3.2  Process  Workflow  Structure 

The  process  workflow  structure  deter¬ 
mines  all  the  aspects  related  to  the  way  in 
which  the  process  is  executed:  the  execution 
order,  the  data  exchange  between  partici¬ 
pants,  the  business  rules,  the  errors  treat¬ 
ment,  etc.  Hence,  two  main  variability 
points  are  identified  in  this  context: 


Control  Flow.  The  workflow  structure 
determines  the  tasks  to  be  executed,  the 
execution  order,  and  even  the  partici¬ 
pant  in  the  process.  Therefore,  the  con¬ 
trol  flow  will  commonly  have  locations 
likely  to  change  in  response  to  changes 
in  the  business  process.  Hence,  for  in¬ 
stance,  suppose  the  travel  agency  de¬ 
cides  to  change  the  order  in  which 
flight  fares  are  consulted  for  certain 
customers,  e.g.,  prioritizing  low-cost 
airlines  for  young  people. 

Data  Flow.  During  the  execution  of  a 
WS-flow,  participants  exchange  differ¬ 
ent  kinds  of  data  in  XML  format.  Simi¬ 
lar  to  the  control  flow,  data  is  likely  to 
change  as  a  consequence  of  implement- 
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ing  changes  in  the  business  process.  As 
an  example,  suppose  the  travel  agency 
is  asked  to  provide  additional  security 
information  in  the  cases  in  which  pas¬ 
sengers  travel  to  a  specific  country. 

B.4  CONCLUSIONS  AND  FUTURE 
WORK 

In  this  paper  we  expose  the  need  for  an 
explicit  classification  of  variability  points  in 
WS-flow  as  a  starting  point  for  handling 
variability  through  services  in  the  context  of 
SPLs  and  SOAs.  In  particular,  we  identify 
and  classify  the  main  variability  points  in 
the  invocation  of  services  and  the  workflow 
structure.  In  some  cases  the  distinction  be¬ 
tween  development-time  and  run-time  is 
exposed  explicitly  because  of  its  relevance. 
However,  we  emphasize  that  the  time  in 
which  variability  is  resolved  will  depend 
mainly  on  the  technology  used. 

Many  challenges  remain  for  our  future 
work.  Once  the  main  variability  points  are 
identified,  it  will  be  necessary  to  consider 
the  available  technological  approaches  for 
implementation.  Hence,  we  are  already 
evaluating  the  different  implementation  pro¬ 
posals  and  are  paying  special  attention  to  the 
way  in  which  they  support  the  variability 
points  presented  in  this  paper. 

Finally,  our  main  goal  is  to  develop  a  proto¬ 
type  development  tool  for  the  generation  of 
a  SPL  of  composite  Web  services.  Although 
our  work  is  still  immature,  we  plan  to  de¬ 
velop  a  framework  for  the  automated  or 
semi-automated  generation  of  BPEL  code 
from  a  given  extended  feature  model  [6], 

The  framework  will  implement  a  core  busi¬ 
ness  process  in  which  variable  parts  will  be 
generated  automatically  according  to  the 
feature  selection.  For  such  purposes,  we  will 
start  by  associating  features  and  feature  at¬ 


tributes  to  Web  services  and  Quality-of- 

Service  (QoS)  parameters  respectively  [5], 
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ABSTRACT 

Service-oriented  computing  develops  appli¬ 
cations  by  composing  services.  In  software 
product  families,  applications  are  developed 
by  reusing  existing  assets.  Hence,  the  ap¬ 
proaches  seem  to  have  several  similarities, 
although  there  are  also  differences.  In  this 
position  paper,  we  discuss  modeling  meth¬ 
ods  in  these  two  approaches.  We  conclude 
with  directions  for  future  studies  for  combin¬ 
ing  modeling  in  software  product  families 
and  service-oriented  computing  that  include 
variability  modeling  in  service-oriented 
computing,  behavior  modeling  and  analysis 
in  software  product  families,  correct  model¬ 
ing  concepts,  unification  modeling  concepts 
in  software  product  families,  and  reuse  and 
a  combination  of  methods  between  ap¬ 
proaches. 

C.1  INTRODUCTION 

Service-oriented  computing  is  a  computing 
paradigm  that  utilizes  services  as  fundamen¬ 
tal  elements  for  developing  applications 
[24].  The  vision  of  such  a  service  is  to  be  in 
place,  and  the  service  must  have  readily 
available  functionality  and  be  a  platform- 
agnostic,  self-describing,  and  location  trans¬ 
parent  computational  element  that  supports 
rapid,  low-cost  composition  of  distributed 
applications.  Typically,  a  service  represents 
a  business  process.  Service-oriented  archi¬ 


tecture  (SOA)  refers  to  a  loosely  coupled 
architectural  style  for  services  [24,  20].  The 
applications  in  service-oriented  computing 
are  developed  by  combining  multiple  ser¬ 
vices  into  one  application  [19]. 

A  software  product  family,  in  turn,  refers  to 
a  set  of  software  products  that  share  a  com¬ 
mon,  managed  set  of  features  satisfying  the 
specific  needs  of  a  particular  market  seg¬ 
ment  or  mission  and  that  are  developed  from 
a  common  set  of  assets  in  a  prescribed  way 
[8],  We  consider  “software  product  line”  to 
be  a  synonym  for  “software  product  family.” 
Software  product  family  architecture  and 
assets  are  developed  in  a  special  domain 
engineering  phase.  The  products  of  a  soft¬ 
ware  product  family  are  derived  by  reusing 
assets  and  potentially  developing  additional 
software.  A  key  facilitator  for  efficient  reuse 
in  a  software  product  family  is  managing 
variability  within  the  assets.  Variability  is  an 
asset’s  ability  to  be  extended,  changed,  cus¬ 
tomized,  or  configured  efficiently  for  use  in 
a  particular  context  [30].  Domain  engineer¬ 
ing  aims  at  introducing  needed  variability 
into  the  assets.  Variability  is  bound  when 
assets  are  reused  in  product  derivation. 

These  two  approaches  seem  to  have  a  great 
deal  in  common.  For  example,  both  aim  at 
efficiently  developing  applications  from 
existing  pieces  of  software.  However,  there 
are  also  differences.  For  example,  typically, 
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services  are  dynamic  computational  ele¬ 
ments  composed  into  applications,  whereas 
the  products  in  a  software  product  family  are 
usually  derived  by  reusing  and  resolving 
variability  in  static  elements,  often  referred 
to  as  components. 

Specifically,  in  both  approaches,  different 
kinds  of  modeling  have  received  a  great  deal 
of  interest.  Within  software  product  fami¬ 
lies,  several  variability  modeling  approaches 
have  emerged;  services  rely  on  descriptions 
of  services  and  modeling  their  compositions 
in  order  to  develop  applications.  In  addition, 
WS-*  standards  [10,  37]  essentially  define 
different  languages  for  expressing  different 
aspects  of  services  as  models.  Since  the  ap¬ 
proaches  share  commonalities,  it  seems  that 
the  modeling  methods  of  one  approach 
could  take  advantage  of  modeling  methods 
in  the  other  approach. 

In  this  position  paper,  we  discuss  the  simi¬ 
larities  and  differences  in  service-oriented 
computing  modeling  and  software  product 
family  modeling.  We  begin  by  briefly  de¬ 
scribing  modeling  in  software  product  fami¬ 
lies  and  service-oriented  computing  in  Sec¬ 
tions  C.2  and  C.3,  respectively.  Section  C.4 
compares  the  similarities  and  differences  of 
the  modeling  methods  in  the  two  ap¬ 
proaches.  In  Section  C.5,  we  discuss  the 
approaches  in  terms  of  how  they  could  bene¬ 
fit  from  modeling  methods  used  in  the  other 
approach.  Finally,  Section  C.6  draws  con¬ 
clusions  for  future  directions  in  combining 
modeling  in  service-oriented  computing  and 
software  product  families. 

C.2  SOFTWARE  PRODUCT  FAMILY 
MODELING 

For  a  software  product  family  model,  it  is 
important  to  be  able  to  express  what  kind  of 
product  variants  can  be  derived  from  the 


assets  at  hand.  Therefore,  many  modeling 
approaches  for  software  product  families 
concentrate  on  introducing  variability.  In 
this  section,  we  outline  different  kinds  of 
variability  modeling  approaches. 

Typically,  there  is  a  differentiation  between 
a  software  product  family  model,  which 
contains  variability,  and  a  product  model,  in 
which  variability  is  bound.  Thus,  a  product 
family  model  expresses  the  rules  and  rela¬ 
tionships  of  how  model  elements  can  be 
combined  within  the  product  model, 
whereas  a  product  model  is  an  instantiation 
of  the  family  model.  This  differentiation 
adheres  to  the  separation  of  domain  engi¬ 
neering  and  product  derivation  in  a  software 
product  family. 

Variability  in  a  software  product  family  en¬ 
compasses  all  software  artifacts  from  re¬ 
quirements  to  code  (cf.  e.g.,  [8,  26]).  Thus, 
there  are  numerous  modeling  methods  that 
aim  at  modeling  variability  within  different 
artifacts  and  at  different  levels  of  abstrac¬ 
tion. 

One  of  the  first  approaches  to  concentrate  on 
modeling  variability  is  FODA  feature  mod¬ 
eling  [17].  A  feature  can  be  defined  as  a  user 
visible  characteristic  of  a  system.  A  feature 
model  is  typically  a  tree  in  which  selections 
are  made  as  to  whether  to  include  features  in 
certain  branches  or  leaves  of  a  product.  Sev¬ 
eral  extensions  to  the  original  feature  model¬ 
ing  have  been  proposed  [9,  18,  1],  In  addi¬ 
tion,  work  has  been  carried  out  to  study  or 
fonnalize  different  feature  modeling  meth¬ 
ods  [14,  1],  Besides  features,  requirements- 
level  artifacts  have  also  been  proposed  to  be 
modeled  utilizing  use  cases  [12,  11]. 

At  the  architectural  level,  Koala  [36]  is  one 
of  the  first  modeling  methods  that  explicitly 
supports  architectural  variability.  Others 
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include  [32,  34,  2,  15].  Thiel  and  Hein  [32] 
present  an  approach  that  adheres  to  and  ex¬ 
tends  the  IEEE  standard  for  documenting 
software  architecture  using  viewpoints  [16]. 
In  addition,  approaches  have  been  intro¬ 
duced  that  provide  integrated  feature  model¬ 
ing  and  architectural  modeling,  which  means 
that  relations  between  features  and  architec¬ 
tural  elements  can  be  modeled  explicitly  [2, 
15], 

In  addition  to  the  above  methods,  which 
include  constructs  for  modeling  software 
artifacts  and  variability  in  the  same  model, 
different  modeling  approaches  that  augment 
software  artifact  models  with  variability 
specific  models  have  been  developed.  The 
artifact  models  can  be  UML  or  other  generic 
software  engineering  modeling  approaches. 
For  example,  orthogonal  variability  model¬ 
ing  (OMV)  [26]  describes  only  variability 
and  constraints  within  variability  in  a  sepa¬ 
rate  model  from  software  artifacts.  This 
variability  model  is  then  used  to  refer  to, 
e.g.,  component  or  process  models  to  ex¬ 
press  the  variability  in  such  a  model.  Cova- 
mof  [28]  is  another  approach  that  has  a  simi¬ 
lar  variability  model,  but  constraints  are 
expressed  in  yet  another  model. 

General-purpose  modeling  methods,  such  as 
UML,  lack  specific  concepts  and  constructs 
for  modeling  the  variability  of  a  software 
product  family,  but  certain  UML  constructs 
can  be  used  to  do  so.  Hence,  primarily,  they 
are  not  meant  to  be  used  for  modeling  vari¬ 
ability,  although  they  can  be  used  to  model 
the  products  of  a  software  product  family. 
Further,  extensions  to  UML  have  been  pro¬ 
posed  to  model  variability  [11].  In  addition, 
since  software  product  family  development 
can  be  considered  a  special  case  of  software 
engineering,  the  commonalities,  i.e.,  the 
parts  that  do  not  contain  variability,  are  fea¬ 
sible  to  model  using  existing  software  engi¬ 
neering  methods,  such  as  UML. 


C.3  SERVICE-ORIENTED 

COMPUTING  MODELING 

In  the  following,  we  outline  modeling  in 
service-oriented  computing.  We  aim  to  pro¬ 
vide  a  general  description.  However,  since 
Web  services  are  currently  the  dominant 
implementation  of  service-oriented  comput¬ 
ing,  most  modeling  approaches  focus  on 
them.  In  addition,  most  concrete  modeling 
approaches  are  developed  for  Web  services. 
Hence,  the  description  is  based  mainly  on 
Web  service  modeling.  Nevertheless,  it 
seems  that  similar  approaches  are  used  in 
other  kinds  of  service-oriented  computing  as 
well. 

Modeling  in  service-oriented  computing  is 
typically  driven  by  different  standards,  such 
as  WSDL  and  BPEL  in  Web  service  model¬ 
ing.  However,  the  standards  are  not  estab¬ 
lished  or  do  not  typically  go  through  a  rigor¬ 
ous  standardization  process  [37]. 
Nevertheless,  the  different  methods  are  de¬ 
veloped  within  a  community,  such  as  the 
World  Wide  Web  Consortium  (W3C)  [31]. 
The  notation  used  for  models  is  usually 
XML,  although  some  graphical  notation  is 
used  as  well. 

Services  differentiate  between  the  descrip¬ 
tion  and  implementation  of  a  service:  A  ser¬ 
vice  description  is  a  model  of  the  service 
consisting  of  the  service  capabilities,  inter¬ 
face,  behavior,  and  quality  [23].  On  the  basis 
of  the  service  description,  the  service  can  be 
used,  i.e.,  found,  bound,  and  composed  in  an 
application.  The  state  of  the  art  in  Web  ser¬ 
vices  is  to  use  WSDL  in  service  descriptions 
[39,  33].  WSDL  is  an  XML -based  notation. 
However,  current  WSDL  and  many  other 
descriptions  have  limitations  in  describing 
semantics  of  the  service  [33]. 

Service  compositions  describe  how  services 
and  operations  of  services  are  glued  together 
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to  provide  composite  services.  That  is,  a 
composition  model  of  services  specifies  the 
order  in  which  the  service  operations  are 
executed  in  a  composite  service  or  an  appli¬ 
cation  [29].  Several  different  service  compo¬ 
sition  approaches  have  been  presented,  such 
as  BPEL  [5]  and  OWL-S  [22], 

Besides  simple  service  composition,  exten¬ 
sions  have  been  proposed  to  cover  concepts 
at  a  more  abstract  level.  Typically,  such 
concepts  try  to  model  business  processes. 
Orriens  et  al.  [21]  present  a  business  col¬ 
laboration  development  framework  and 
modeling  method  including  language  for 
specifying  rules.  The  framework  takes  into 
account  different  levels  of  abstraction  and 
different  points  of  view.  Business-driven 
automated  composition  is  another  approach 
that  roughly  means  specifying  requirements 
at  the  business  level  and  then,  from  the  re¬ 
quirements,  deriving  service  composition 
automatically  [25].  Business  Process  Model¬ 
ing  Notation  (BPMN)  [6]  of  OMG  provides 
notation  for  a  high-level  description  of  a 
business  process.  In  addition,  a  mapping 
from  BPMN  to  BPEL  providing  automatic 
generation  has  also  been  described  [38]. 

Several  different  aspects  for  Web  services 
are  described  in  specifications  referred  to  as 
WS-*.  However,  there  are  numerous  differ¬ 
ent  specifications,  and  few  of  them  have 
gained  an  established  position  despite  being 
called  standards  [37]. 

C.4  COMPARISON 

Software  product  family  modeling  and  ser¬ 
vice  modeling  have  several  similarities  but 
also  differences.  In  this  section,  we  compare 
these  similarities  and  differences. 


C.4.1  Domain  and  Product  Modeling 

Software  product  family  modeling  involves 
domain  and  product  models.  The  entities  of 
domain  modeling  are  instantiated  in  product 
models.  However,  the  main  focus  in  soft¬ 
ware  product  families  is  on  modeling  the 
domain  and  describing  the  variability  of  a 
software  product  family.  Further,  not  all 
approaches  explicitly  address  instance  mod¬ 
els.  Service-oriented  computing  focuses 
mainly  on  modeling  the  products,  i.e.,  ser¬ 
vice  compositions.  Despite  service  models 
using  WSDL  being  considered  models  of 
reusable  entities,  there  is  no  modeling  of 
possible  service  compositions  or  rales  for 
service  composition  similar  to  models  con¬ 
taining  variability  in  software  product  fami¬ 
lies. 

C.4.2  Composition  vs.  Decomposition 

A  software  product  family  typically  decom¬ 
poses  artifacts  into  fine  grained  artifacts, 
whereas  service-oriented  computing  is  a 
bottom-up  compositional  approach  to  com¬ 
bine  artifacts  into  larger  entities.  Decompo¬ 
sition  or  top-down  modeling  means  that  a 
software  product  family  architecture  speci¬ 
fies  the  decomposition  of  a  family  into  ar¬ 
chitectural  components.  However,  there  are 
also  software  product  family  approaches, 
such  as  product  populations  modeled  using 
Koala  [35],  in  which  the  approach  is  a  mix¬ 
ture  of  bottom-up  and  top-down  approaches. 
In  service-oriented  computing,  there  is  typi¬ 
cally  no  special  architecture  that  specifies 
the  decomposition.  Rather,  the  SOA  defines 
only  architectural  style  for  applications,  and 
application  development  is  a  compositional 
approach  from  small  services  into  larger 
composite  services  that  finally  form  the  ap¬ 
plications.  The  models  in  service-oriented 
computing  are  developed  similarly  to  de¬ 
scribe  such  compositions  bottom  up  from 
single  services  to  compositions  of  service. 
However,  technically,  there  is  nothing  to 
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prevent  decomposition  in  services  or  com¬ 
position  in  software  product  families. 

C.4.3  Modeling  Concepts 

Both  approaches  use  different  modeling  arti¬ 
facts,  such  as  those  corresponding  to  re¬ 
quirements  and  executable  software  entities. 
However,  both  approaches  focus  primarily 
on  modeling  concerns  at  architectural  level 
entities:  In  service-oriented  computing, 
these  are  services,  while  in  software  product 
families,  these  are  different  kinds  of  archi¬ 
tectural  entities,  such  as  processes  and  com¬ 
ponents.  Central  in  both  approaches  are  also 
entities  roughly  corresponding  to  require¬ 
ments,  i.e.,  features  in  software  product 
families  and  business  processes  in  service- 
oriented  computing.  Modeling  in  a  software 
product  family,  especially  in  case  of  OVM 
[26],  can  also  take  into  account  software 
models  such  as  detailed  design  artifacts.  The 
main  difference  is  that  modeling  in  a  soft¬ 
ware  product  family  concerns  different 
kinds  of  entities,  including  static  and  dy¬ 
namic  ones,  whereas  service-oriented  com¬ 
puting  models  concerns  only  dynamic  enti¬ 
ties.  Typically,  software  product  families 
focus  on  static  entities. 

C.4.4  Relations  in  Models 

Both  software  product  families  and  service- 
oriented  computing  model  basic  relations 
between  entities,  such  as  the  compositional 
structure  of  components  or  services  and 
connections  between  the  interfaces  of  com¬ 
ponents  or  services.  In  addition,  both  ap¬ 
proaches  aim  at  relationships  between  the 
requirements  models  and  the  implementa¬ 
tion  models.  Such  relationships  can  be  used 
to  generate  the  composition  of  lower-level 
entities.  That  is,  from  features  can  be  de¬ 
rived  component  compositions  in  software 
product  families,  and  from  business  proc¬ 
esses  can  be  derived  service  compositions  in 


service-oriented  computing.  However,  in  a 
software  product  family,  also  modeled  are 
more  complex  relations  such  as  required  or 
excluded  relations  in  a  variability  model. 

C.4.5  Modeling  Notations 

Software  product  families  rely  on  different 
kinds  of  modeling  notation,  some  of  which 
build  on  or  augment  state  of  the  practice 
notations,  such  as  UML,  and  some  being 
peculiar  to  software  product  families,  such 
as  feature  modeling.  Typically,  such  nota¬ 
tion  has  graphical  syntax,  although  its  tex¬ 
tual  counterpart  is  sometimes  also  specified. 
Often,  each  variability  modeling  approach 
introduces  its  own  notation  or  at  least 
changes  existing  notation  a  bit.  Service- 
oriented  computing,  in  turn,  relies  mainly  on 
XML-based  notation.  Consequently,  the 
modeling  notation  in  software  product  fami¬ 
lies  and  service-oriented  computing  differ 
quite  significantly. 

C.4.6  Establishment 

Software  product  family  modeling  is  charac¬ 
terized  by  different  modeling  initiatives, 
whereas  service-oriented  computing  strives 
for  standards.  However,  the  standards  in 
service-oriented  computing  are  not  clearly 
established.  Instead,  there  are  several  com¬ 
peting  standards.  Frequently,  standardiza¬ 
tions  merely  claim  a  notation  to  be  standard 
without  passing  through  a  rigorous  stan¬ 
dardization  process.  Nevertheless,  the  mod¬ 
eling  approaches  in  service-oriented  com¬ 
puting  are  often  created  by  a  community  or 
at  least  several  companies,  whereas  for 
software  product  families,  the  modeling 
methods  are  created  by  individual  research¬ 
ers  or  research  groups.  For  example,  numer¬ 
ous  different  feature  modeling  methods  have 
been  proposed  that  do  not  differ  signifi¬ 
cantly  from  each  other  [1], 
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C.4.7  Stakeholders 

Software  product  family  modeling  takes  into 
account  a  wider  scope  of  stakeholders  than 
is  typically  done  in  service  modeling.  That 
is,  software  product  family  modeling  ad¬ 
heres  to  conventions  of  viewpoint-based 
software  architecture  description  that  ac¬ 
knowledge  a  large  group  of  different  stake¬ 
holders  (cf.  [7,  27]).  Software  product  fam¬ 
ily  modeling  takes  into  account  stakeholders 
from  developers  to  customers.  Service  orien¬ 
tation,  in  contrast,  typically  does  not  address 
operation  or  deployment;  hence,  modeling 
is,  in  that  respect,  more  limited. 

C.5  DISCUSSION 

A  major  difference  between  the  approaches 
from  the  service  point  of  view  is  the  lack  of 
domain  modeling  or  variability  modeling  in 
service-oriented  computing,  although  ser¬ 
vice-oriented  computing  aims  at  efficiently 
composing  different  composition  services, 
i.e.,  product  variants,  from  existing  services. 
Such  a  variability  model  would  express  rales 
for  different  applications  or  service  compo¬ 
sitions. 

On  the  one  hand,  service-oriented  comput¬ 
ing  is,  in  principle,  a  compositional  ap¬ 
proach  in  which  services  are  composed  to 
applications.  Hence,  establishing  a  domain 
model  in  service-oriented  computing  would 
restrict  the  composition  and  would  stand  in 
stark  contrast  to  service  composition  princi¬ 
ples. 

On  the  other  hand,  service-oriented  comput¬ 
ing  is  usually  applied  in  the  context  of  busi¬ 
ness  processes.  It  seems  that  such  processes 
have  several  constraints  in  terms  of  how 
they  can  be  composed.  The  constraints  may 
originate  from  meaningful  process  order, 
i.e.,  some  information  needs  to  exist  before  a 
process  can  proceed  -  from  policies  set  by  a 


company,  i.e.,  certain  information  may  not 
be  shared  with  outsiders.  Therefore,  it  seems 
feasible  to  introduce  domain  modeling  in 
service-oriented  computing  to  constrain  ser¬ 
vice  composition  at  least  to  certain  applica¬ 
tion  domains. 

In  addition,  although  originally  software 
product  families  have  been  strictly  decom¬ 
position-driven  approaches  such  that  the 
products  of  a  software  product  family  are 
determined  by  the  software  product  family 
architecture  [3,  8],  recently  different  initia¬ 
tives  toward  more  composition-oriented  ap¬ 
proaches  have  been  proposed  [35,  4].  Con¬ 
sequently,  a  challenge  also  to  variability 
modeling  is  to  develop  methods  that  do  not 
require  strict  structural  architecture  but 
rather  enable  the  expression  of  principles, 
design  rules,  and  design  constraints  [4]. 

From  the  point  of  view  of  software  product 
families,  modeling  in  service-oriented  com¬ 
puting  seems  more  restricted  in  terms  of 
scope,  which  focuses,  at  the  architectural 
level,  mainly  on  the  behavior  of  systems. 
That  is,  there  are  several  different  view¬ 
points  adhering  to  the  concept  of  an  archi¬ 
tectural  viewpoint  that  can  be  used  to  model 
a  software  product  family,  whereas  service- 
oriented  computing  models  mainly  behavior 
at  the  level  of  service  and  business  proc¬ 
esses.  However,  software  product  families 
typically  concentrate  on  the  static  modeling 
of  components,  and  other  concepts  have  not 
received  as  much  attention.  In  fact,  many 
architectural  variability  modeling  methods 
contain  constructs  primarily  for  static  ele¬ 
ments.  Hence,  the  modeling  concepts  for 
modeling  dynamic  aspects  in  software  prod¬ 
uct  families  could  be  taken  from  service- 
oriented  computing. 

Further,  service-oriented  computing  studies 
different  kinds  of  verification  techniques  for 
behavior  [25,  19].  These  techniques  could 
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also  be  applied  to  verification  of  the  applica¬ 
tion  of  a  software  product  family. 

In  addition,  at  the  level  of  user  visible  char¬ 
acteristics,  software  product  families  pre¬ 
dominantly  rely  on  feature  models,  although 
use  cases  and  other  methods  have  been  pro¬ 
posed  as  well.  Nevertheless,  other  modeling 
concepts  that  could  be  used  in  software 
product  families  are  business  process  model¬ 
ing  of  services.  In  particular,  business  proc¬ 
ess  modeling  seems  feasible  for  software 
product  families  of  information  systems. 

This  plethora  of  modeling  concepts  in  soft¬ 
ware  product  families  and  the  few  concepts 
in  service-oriented  computing  raises  the 
question  of  what  modeling  concepts  should 
be  used  in  service-oriented  computing  or 
software  product  families.  Not  all  modeling 
concepts  of  software  product  families  are 
directly  applicable  to  service-oriented  com¬ 
puting.  Nevertheless,  it  seems  that  service 
modeling  could  be  based  on  a  similar  view¬ 
point-based  approach  [16],  as  architectural 
modeling  can  also  be  applied  in  software 
product  families.  However,  the  modeling 
concepts  of  service-oriented  computing  can 
be  at  least  partially  different  than  those  typi¬ 
cally  applied  in  software  architecture  model¬ 
ing.  For  example,  four  different  viewpoints 
have  been  proposed  for  configurable  service 
modeling  [13]. 

A  notable  difference  is  that  modeling  in  ser¬ 
vice-oriented  computing  is  mostly  based  on 
XML -based  languages  and  developed  within 
a  certain  kind  of  community,  although  such 
a  community  can  be  relatively  small  [37]. 
Some  methods  have  gained  an  established 
position  relatively  quickly  such  as  BPEL  or 
WSDL.  Typically  such  methods  are  de¬ 
scribed  thoroughly  in  standards,  and  many 
are  familiar  with  them.  Within  software 
product  families  similar  established  nota¬ 
tions  are  lacking.  Instead,  there  is  a  plethora 


of  different  notations,  which  differ  from 
each  other  slightly  and  which  are  even  hard 
to  differentiate  from  each  other.  Established 
methods  are  needed  in  service-oriented 
computing,  since  such  service  can  be  devel¬ 
oped  by  different  parties.  Software  product 
families  differ  in  that  they  are  not  typically 
intra-organizational,  hence  understanding  of 
the  methods  need  not,  in  that  respect,  be  as 
wide.  Nevertheless,  since  service-oriented 
computing  has  succeeded  in  achieving  such 
established  forms  of  notation,  it  seems  that 
software  product  family  modeling  could  also 
aim  at  a  more  coherent  conceptual  basis  and 
notation.  This  is  especially  needed,  if  vari¬ 
ability  modeling  is  to  be  applied  in  a  wider 
context  than  intra-organizationally,  such  as 
in  service-oriented  computing. 

Finally,  despite  the  differences,  combined 
modeling  methods  could  be  developed,  e.g., 
for  behavior  modeling,  in  which  the  same 
concepts  are  used  for  software  product  fami¬ 
lies  and  service-oriented  computing.  Such  an 
approach  could  even  combine  notation: 
modeling  in  software  product  families  could 
provide  graphical  representations,  whereas 
modeling  in  service-oriented  computing 
could  provide  the  textual  format. 

C.6  CONCLUSIONS 

In  this  paper,  we  discussed  and  compared 
modeling  in  service-oriented  computing  and 
software  product  families.  While  the  aim  of 
both  approaches  is  relatively  similar,  there 
are  notable  differences.  This  study  suggests 
the  following  challenges  for  further  study: 
First,  extensibility  and  feasibility  of  variabil¬ 
ity  modeling  should  be  studied  in  the  con¬ 
text  of  service-oriented  computing.  Second, 
variability  modeling  in  software  product 
families  should  take  a  lesson  from  behavior 
modeling  and  analysis  of  services  and  busi¬ 
ness  processes  in  service-oriented  comput¬ 
ing.  Third,  the  necessary  concepts  for  the 
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modeling  of  services  and  software  product 
families  should  be  studied  more  thoroughly. 
Fourth,  variability  modeling  in  software 
product  families  should  aim  toward  unifying 
the  fragmented  conceptual  foundations  and 
notation.  Finally,  it  seems  feasible  for  both 
approaches  to  apply  and  reuse  modeling 
methods  from  other  approaches. 
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ABSTRACT 

The  concept  of  sendee  orientation  (SO)  is 
a  relevant  promising  candidate  for  accommo¬ 
dating  rapidly  changing  user  needs  and  ex¬ 
pectations.  Adopting  SO  in  practice  for  real 
software  and  system  development,  however, 
has  uncovered  several  challenging  issues, 
such  as  maintaining  consistent  system  con¬ 
figuration  or  integrity  of  dynamically  com¬ 
posed  services,  or  identifying  reusable  ser¬ 
vices  at  the  right  level  of  granularity.  In  this 
paper,  we  propose  an  approach  that  ad¬ 
dresses  the  latter  issue,  which  we  map  to  the 
well-known  challenge  of  defining  reusable 
software  assets.  The  approach  is  adapted 
from  the  analysis  technique  of  product  line 
engineering,  which  is  the  most  successful  ap¬ 
proach  for  establishing  reuse  in  practice.  We 
present  how  reusable  services  can  be  identi¬ 
fied  and  specified  based  on  features:  these 
features  identify  variations  of  a  family  of 
products  from  a  user’s  point  of  view’  and  thus 
will  be  the  subjects  of  reconfigurations  of  ser¬ 
vice  centric  systems  at  runtime. 

D.1  INTRODUCTION 

The  concept  of  service  orientation  (SO)  is 
a  relatively  new  paradigm  for  software  devel¬ 
opment:  systems  are  no  longer  developed, 


integrated,  and  released  in  a  centrally  syn¬ 
chronized  way,  but  services  are  developed 
and  deployed  independently  and  separately, 
as  well  as  composed  as  late  as  at  runtime  if 
and  when  needed  only.  That  is,  service  con¬ 
sumers  are  mostly  decoupled  from  service 
providers.  This  corresponds  to  the  main  prop¬ 
erty  of  SO:  a  great  amount  of  inherent  flexi¬ 
bility.  This  flexibility  leads  to  perfect  seal- 
ability  characteristics  because  a  network  can 
be  populated  by  as  many  services  as  wanted 
but  only  affect  the  systems  that  actually  re¬ 
quire  them. 

User  needs  and  expectations  change  con¬ 
tinuously,  and  thus  software  systems  must 
evolve  rapidly,  to  accommodate  user  expecta¬ 
tions.  More  and  more  software  systems  are 
connected  to  the  Internet,  and  thus  their  evo¬ 
lution  could  be  supported  and  accelerated  by 
dynamically  adding  and  integrating  services. 
Hence,  the  SO  paradigm  is  a  relevant  promis¬ 
ing  candidate  for  addressing  evolution  chal¬ 
lenges.  Thus  SO  has  gained  great  attention  by 
practitioners,  as  well  as  by  researchers. 

Adopting  SO  in  practice  for  real  software 
and  system  development,  however,  has  un¬ 
covered  several  challenging  issues,  such  as 
maintaining  consistent  system  configuration 
or  integrity  of  dynamically  composed  ser- 
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vices,  or  identifying  services  at  the  right  level 
of  granularity.  In  this  position  paper,  we  pro¬ 
pose  an  approach  that  addresses  the  latter  is¬ 
sue  by  mapping  it  to  the  well-known  chal¬ 
lenge  of  defining  reusable  software  assets.  In 
SO,  a  service  is  the  basic  building  block  for 
system  construction.  Thus  integrating  existing 
services,  which  were  developed  in  potentially 
different  contexts  by  different  people,  means 
nothing  else  than  reusing  software. 

The  reuse  process  consists  of  several  steps: 
identification  of  reuse  candidates,  evaluation 
of  these  candidates,  selection  of  the  best  reuse 
candidate  for  the  given  context,  and  adapta¬ 
tion  and  integration  of  the  selected  candidate 
into  the  system  under  development.  There  are 
many  experience  reports  that  emphasize  prob¬ 
lems  and  challenges  in  implementing  software 
reuse  in  general.  Reusing  a  service  corre¬ 
sponds  to  the  reuse  of  a  component  providing 
a  single  method  only.  From  our  point  of  view, 
realizing  the  reuse  of  services  is  nevertheless 
more  challenging  than  realizing  the  reuse  of 
components.  That  is  because  the  SO  reuse 
process  is  supposed  to  be  executed  automati¬ 
cally  by  a  software  system  at  runtime  without 
any  consultation  of  human  experts. 

In  our  research,  we  investigate  this  reuse 
aspect  as  an  inherent  part  of  the  SO  para¬ 
digm’s  nature.  We  apply  the  concepts  of 
product  line  engineering — which  is  the  most 
successful  approach  for  establishing  reuse  in 
practice — to  the  SO  paradigm.  That  is,  we 
tailor  Fraunhofer  PuLSE™  (Product  Line 
Software  and  System  Engineering)  [1]  to  the 
SO  paradigm  and  thus  enable  the  efficient 
construction  and  evolution  of  service  centric 
software  systems. 


PuLSE  is  a  registered  trademark  of  the  Fraunhofer 
Institute  for  Experimental  Software  Engineering 
(IESE)  in  Kaiserslautern,  Germany. 


D.2  APPROACH  OVERVIEW 

In  this  position  paper,  we  propose  a  tech¬ 
nique  for  identifying  and  specifying  reusable 
services.  This  technique  is  based  on  analyzing 
and  specifying  features  that  may  vary  from  a 
user’s  point  of  view  and  thus  will  be  subjects 
of  reconfigurations  at  runtime. 

Figure  D-l  shows  activities  and  their  rela¬ 
tionships  to  the  technical  components.  These 
activities  are  executed  iteratively;  the  arrows  in 
Figure  D-l  indicate  the  flow  of  data  and  which 
work  products  are  used  by  each  activity. 

A  feature  analysis  organizes  product  family 
features  into  an  initial  model,  which  is  then 
refined  by  adding  design  features  such  as  oper¬ 
ating  enviromnents,  domain  technologies,  or 
implementation  techniques.  Within  the  feature 
model,  the  subsequent  binding  analysis  identi¬ 
fies  binding  units  and  determines  their  relative 
binding  times  among  each  of  the  others  [2], 

The  service  analysis  consumes  the  results  of 
these  analyses.  Each  binding  unit  is  further 
analyzed  to  determine  its  service  category  (i.e., 
orchestrating  service  or  molecular  service) 
with  respect  to  the  particular  family  at  hand. 

We  assume  here  families  whose  variations  can 
be  described  best  by  variations  in  workflows 
executed  by  the  system  users.  Additionally,  the 
context  and  the  technical  infrastructures  avail¬ 
able  vary,  and  thus  dynamic  reconfigurations 
of  product  variants  are  expected. 

The  mass  of  low  level  services,  that  we  call 
atomic  services,  are  grouped  into  richer  ser¬ 
vices  as  required  by  the  family.  These  richer 
services  are  (virtually)  composed  of  atomic 
services  and  are  thus  called  molecular  services. 
Note  that  each  product  family  has  thus  its  own 
specific  set  of  molecules,  the  basic  building 
blocks  for  constructing  family  members.  Due 
to  the  definition  of  those  molecules  based  on 
product  line  processes,  molecular  services  are 
more  reusable  than  atomic  services  (in  the 
context  of  a  particular  product  family). 
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-  Locality  of  tasks 


Figure  D-1: 

From  a  technical  viewpoint,  the  identified 
services  are  specified  first  as  workflows  and 
their  constituting  tasks.  Then,  their  pre/post 
conditions,  invariants,  and  service  interfaces 
are  specified.  Note  that  also  the  quality  of 
services  (QoS)  may  vary  due  to  different  ser¬ 
vice  configurations.  Finally,  the  system  inte¬ 
gration  and  deployment  activity  form  a  prod¬ 
uct  by  integrating  the  reusable  services 
provided  by  the  previous  activities. 

For  illustrating  the  approach  presented  in 
this  paper,  we  selected  a  case  study  in  the 
domain  of  the  virtual  office  of  the  future 
(VOF).  The  VOF  product  family  consists  of 
systems,  which  control  and  manage  collec¬ 
tions  of  devices  to  provide  any-time  any¬ 
where  office  environments  [9]. 

D.3  FEATURE  ANALYSIS 

In  this  section,  activities  of  feature  analy¬ 
sis — which  includes  feature  modeling  and 
feature  binding  analysis — are  introduced.  Fea¬ 
ture  modeling  is  the  activity  of  identifying 
externally  visible  characteristics  of  products 
in  a  product  line  and  organizing  them  into  a 
model  called  feature  model  [10].  Figure  D-2 
shows,  for  instance,  a  part  of  the  feature 
model  for  the  VOF  product  line.  The  primary 
goal  of  feature  modeling  is  to  identify  com¬ 
monalities  and  differences  of  products  in  a 
product  line  and  represent  them  in  an  exploit¬ 
able  form,  i.e.,  a  feature  model. 


Activities  of  the  Approach 

Common  features  among  different  prod¬ 
ucts  in  a  product  line  are  modeled  as  manda¬ 
tory  features  (e.g.,  Resource  Manager  and 
Follow  Me),  while  different  features  among 
them  may  be  optional  (e.g.,  Auto  Log-on)  or 
alternative  (e.g.,  User  Positioning  Method). 
Optional  features  represent  selectable  features 
for  products  of  a  given  product  line,  and  al¬ 
ternative  features  indicate  that  no  more  than 
one  feature  can  be  selected  for  a  product.  De¬ 
tails  of  feature  analysis  and  guidelines  can  be 
found  in  [10]. 

Once  we  have  a  feature  model,  it  is  further 
analyzed  through  feature  binding  analysis  [2], 
Feature  binding  analysis  consists  of  two  ac¬ 
tivities:  feature  binding  unit  identification  and 
feature  binding  time  determination.  Feature 
binding  unit  identification  starts  with  identifi¬ 
cation  of  service  features.  A  service  feature 
represents  a  major  functionality  of  a  system 
and  may  be  added  or  removed  as  a  service 
unit.  In  VOF,  Follow  Me,  Resource  Manage¬ 
ment,  Virtual  Printer,  and  Smart  Business 
Trip  features  are  examples  of  service  features. 

A  set  of  features  that  should  be  included  in  a 
feature  binding  unit  are  identified  by  travers¬ 
ing  the  feature  model  along  feature  relation¬ 
ships.  For  example.  Follow’  Me,  User  Authen¬ 
tication,  Manual  Log-on,  Auto  Log-on,  User 
Positioning  Method,  Access  Point  based 
Method,  and  RFID  based  Method  belong  to 
the  FOLLOW  ME  feature  binding  unit.  Note 
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Figure  D-2:  A  Feature  Model  and  Binding  Units  of  VOF  [11] 


that  the  optional  A  UTO  LOG-ON  and  the  al¬ 
ternative  USER  POSITIONING  METHOD  are 
identified  as  separate  feature  binding  units, 
because  they  may  have  different  binding  time 
from  their  parent  feature  binding  units.  (See 
Figure  D-2  for  their  identification.)  Note  that 
alternative  variants  of  an  alternative  feature 
binding  unit  are  listed  in  parentheses  (e.g.,  AP 
or  RFID  for  USER  POSITIONING  METHOD 
in  Figure  D-2.) 

Because  a  feature  binding  unit  contains  a 
set  of  features  that  need  to  be  bound  together 
into  a  product  to  provide  a  service  correctly 
and  share  the  same  binding  time,  a  product 
can  be  considered  as  a  composition  of  feature 


binding  units.  By  taking  these  feature  binding 
units  as  a  key  driver  for  service  analysis,  we 
could  alleviate  the  difficulties  for  identifying 
candidate  services  with  right  granularity,  i.e., 
reusable  services. 

In  the  next  section,  how  the  identified  can¬ 
didate  services  (i.e.,  feature  binding  units)  are 
further  classified  and  refined  is  explained. 

D.4  SERVICE  ANALYSIS 

Through  the  previous  activities,  we  now 
have  a  feature  model  and  feature  binding  in¬ 
formation,  which  provides  an  insight  into  a 
targeting  domain  in  terms  of  product  features, 
basic  units  of  binding,  and  their  binding  time. 
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Then,  the  feature  model  is  refined  and  restruc¬ 
tured  by  introducing  a  separation  of  two 
distinctive  service  characteristics:  behavioral 
(workflow)  and  computational  (tasks)  service 
characteristics. 

A  behavior  oriented  service  is  mainly  to 
define  a  certain  sequence  of  tasks,  i.e.,  work¬ 
flows.  We  call  services  in  this  category  or¬ 
chestrating  services,  as  their  main  role  is  the 
composition  of  other  services  in  a  harmonious 
way.  A  computation  oriented  service  is  to 
provide  computational  outputs  (i.e.,  a  prede¬ 
fined  task)  in  response  to  given  inputs.  We 
call  services  in  this  category  molecular  ser¬ 
vices,  as  they  are  the  basic  building  blocks 
and  will  be  reused  as-is  by  orchestrating  ser¬ 
vices.  Details  of  services  that  belong  to  each 
category  are  explained  in  the  following  sec¬ 
tions.  (See  Figure  D-3  for  the  refined  feature 
model  with  the  two  service  layers.) 

D.4.1  Orchestrating  Service 

For  orchestrating  services,  correctness  of 
their  overall  control  behavior  is  the  foremost 
concern.  For  example,  providing  an  expensive 
color-printing  service  with  proper  authoriza¬ 
tion  and  billing  processes  is  critical  for  virtual 
office  service  providers.  Therefore,  adopting  a 
formal  method  framework  to  specify,  vali¬ 
date,  and  verify  is  the  most  suitable  way  for 
developing  orchestrating  services.  In  our  ap¬ 
proach,  we  adapted  a  workflow  specification 


language  [11]  with  pre/post  conditions  and 
invariants  to  enhance  the  reliability  of  specifi¬ 
cations. 

Figure  D-4  shows  a  workflow  specification 
example  for  a  business  trip  service.  Each  or¬ 
chestrating  service  has  pre/post  conditions 
and  invariants.  In  this  example,  a  user  should 
be  logged  in  to  trigger  the  service,  and  the 
workflow  is  completed  only  after  the  user 
submits  a  postmortem  report  about  her/his 
business  trip.  Also,  the  invariants  (i.e.,  the 
user  is  employed  and  the  business  trip  is  not 
cancelled)  should  hold  through  the  whole 
workflow  process.  When  ever  the  invariants 
become  invalid,  the  workflow  is  terminated 
with  proper  notifications  to  relevant  stake¬ 
holders. 

Moreover,  each  task  of  the  workflow  can 
be  specified  with  its  pre/post  conditions  and 
invariants.  For  example,  a  secretary  should 
achieve  the  access  rights  to  organizational 
data  such  as  the  charged  project’s  budget  in¬ 
formation  and  the  traveler’s  bank  account 
number  to  proceed  with  the  reservation  task. 
Such  conditions  can  be  defined  as  the  precon¬ 
dition  of  the  reservation  task  and  checked 
when  a  secretary  is  assigned  for  the  task.  Note 
that  the  consistency  of  invariants  between  a 
workflow  and  its  constituting  tasks  should  be 
checked  when  an  orchestrating  service  is 
specified. 
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In  addition  to  the  identification  of  tasks 
and  their  pre/post  conditions  and  invariants 
for  an  orchestrating  service,  the  locality  of 
each  task  should  also  be  identified  for  high 
availability  of  services.  By  locality  we  mean 
that  the  information  of  the  responsible  person 
of  a  task  and  her/his  physical  location  where 
the  task  is  performed.  The  locality  informa¬ 
tion  is  particularly  important  for  a  domain.  In 
addition  to  the  identification  of  tasks  and  their 
pre/post  conditions  and  invariants  for  an  or¬ 
chestrating  service,  the  locality  of  that  should 
support  mobility  of  users  like  the  VOF  sys¬ 


tems.  For  instance,  the  visa  process  and  reser¬ 
vation  tasks  are  local  to  a  secretary,  and  they 
can  be  processed  without  the  coordination  at 
the  global  level.  This  means  that  the  secretary 
can  perform  the  tasks  locally  although  she/he 
is  disconnected  from  a  network.  Also,  the 
physical  location  is  important  to  assign  the 
most  relevant  business  peripherals  such  as  a 
printer  or  a  fax  machine.  However,  the  ap¬ 
proval  status  of  a  business  trip  by  a  deciding 
staff  should  be  managed  at  the  global  level  to 
trigger  tasks  that  belong  to  other  persons. 
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Figure  D-4:  An  Example  of  Workflow  Specification  for  an  Orchestrating  Service:  Smart  Business  Trip 


Next,  the  identification  and  specification  of 
molecular  services  are  explained. 

D.4.2  Molecular  Services 

The  identification  of  molecular  services 
with  right  granularity  is  the  key  factor  to  en¬ 
hance  reusability  of  the  service  centric  system 
development.  Molecular  services  are  the  basic 
units  for  reuse,  and  orchestrating  services 
should  be  able  to  compose  them  as-is  through 
their  interfaces  during  development  time  or 
their  runtime.  For  their  identification,  feature 
binding  units  are  analyzed  and  refined  with 
consideration  of  the  following  guidelines.  A 
molecular  service  should  be 

•  self-contained  (local  control  and  local 
computation) 

•  stateless  from  service  user’s  point  of  view 

•  provided  with  pre/post  conditions 

•  representative  of  a  domain-specific  ser¬ 

vice 

The  first  three  guidelines  are  to  decouple 
service  consumers  from  providers.  Based  on 
these  guidelines,  a  service  consumer  only 


needs  to  know  the  service  providers’  interface 
and  their  conditions  for  use.  This  means  that 
any  changes  (performance  improvements  bug 
patches,  etc.)  within  an  identified  molecular 
service  must  not  be  propagated  to  other  ser¬ 
vices. 

The  last  guideline  is  the  key  factor  to  de¬ 
termine  the  right  granularity  of  a  molecular 
service  based  on  the  feature  binding  unit  and 
time  information,  and  domain  experts’  profes¬ 
sional  judgment.  For  instance,  the  feature 
binding  units  related  to  Follow’  Me  and  its 
descendent  feature  binding  units  in  figure  D-2 
are  identified  and  reorganized  as  the 
FOLLOW  ME  molecular  service  in  Figure  D- 
3.  The  rationale  for  this  determination  is  as 
follows: 

•  the  Follow’  Me  feature  is  a  mandatory 

service  for  every  user  of  the  VOF  prod¬ 
uct  line 

•  each  localizing  device  (e.g.,  RFID,  access 
points  of  wireless  networks,  etc.)  uses 
different  localization  techniques,  but  its 
expected  outputs  are  the  same  (e.g.,  a 
user’s  physical  location) 
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1:  molecular  service  FOLLOW  ME  (user  User) 

2:  invariants  user . IESE_Employee  ==  true 
3:  precondition  user . authentif ication  ==  logged_in 

4:  postcondition  none; 

5:  option  Environment  Visualization 

6:  binding  time  run  time 

7:  precondition  user. device  ==  desktop  v  notebook 

8:  pos tcondi tion  none; 

9:  option  Automatic  Log-on 

10:  binding  time  run  time 

11:  precondition  user. rank  ==  director  v  manager  and 

12 :  RFID  bases  user  location  method  ==  available 

13:  pos  tcondi tion  user. access  ==  granted  v  rejected; 

Figure  D-5:  An  Example  of  Molecular  Service  Specification 


•  the  implementing  algorithms  for  localiza¬ 

tion  evolve  rapidly  to  improve  their  ac¬ 
curacy 

•  it  is  a  computation  oriented  service  with¬ 

out  any  workflows  in  it 

Based  on  this  decision,  the  FOLLOW  ME 
molecular  service  is  designed  and  imple¬ 
mented  to  provide  the  user  localization  ser¬ 
vice  to  the  orchestrating  services,  if  they 
abide  by  the  pre/post  conditions  of  FOLLOW 
ME. 

Each  molecular  service  may  have  its  QoS 
parameters,  which  are  identified  during  the 
feature  binding  analysis  in  terms  of  optional 
or  alternative  features.  For  example,  the  User 
Positioning  Method  feature  binding  unit  has 
two  alternatives  (e.g.,  AP-based  and  RFID- 
based  method),  and  their  levels  of  accuracy 
are  different  (e.g.,  the  error  range  of  the 
RFID-based  method  is  less  than  1  meter, 
whereas  the  error  range  of  the  AP-based 
method  is  less  than  10  meters).  Depending  on 
available  devices  near  a  user,  one  of  the  alter¬ 
native  positioning  methods  is  selected  and 
used. 

In  our  approach,  each  molecular  service  is 
specified  by  using  a  text-based  specification 
template,  and  Figure  D-5  shows  the  specifica¬ 
tion  of  FOLLOW  ME.  (The  characters  in  the 


bold  font  are  reserved  words  for  the  specifica¬ 
tion.)  The  FOLLOW  ME  service  is  for  the 
current  employees,  who  passed  the  authenti¬ 
cation  and  logged  in.  Also,  the  Automatic 
Log-on,  which  is  optional  for  higher  quality 
of  the  service,  is  only  available  at  runtime 
when  the  requesting  user’s  job  function  is 
director  or  manager,  and  an  RFID  device  is 
available  nearby.  (See  the  lines  9  to  13  for  the 
specification  of  optional  feature  Automatic 
Log-on .) 

In  this  section,  concepts  and  guidelines  for 
analyzing  and  specifying  orchestrating  and 
molecular  services  are  explained.  The  next 
section  discusses  and  evaluates  our  approach. 

D.5  RELATED  WORK 

While  our  approach  concentrates  on 
achieving  reusability  by  means  of  proper 
identification  and  specification  of  services 
using  product  line  technologies,  in  [3],  reus¬ 
ability  is  claimed  to  be  achieved  by  the  struc¬ 
ture  of  systems  and  the  interaction  mecha¬ 
nisms.  This  mainly  means  the  availability  of  a 
service  repository  and  the  concepts  for  dis¬ 
covering,  negotiating,  and  binding  services. 

IBM  developed  a  method,  called  “Service- 
Oriented  Modeling  and  Architecture”  [4,  5].  It 
provides  guidelines  for  three  steps  towards 
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SO  systems:  identification,  specification,  and 
realization  of  services,  flows,  and  compo¬ 
nents.  In  particular,  a  combination  of  three 
complementary  ideas  is  proposed  to  identify 
services  in  [4].  First,  the  domain  of  the  re¬ 
spective  software  systems  is  analyzed  and 
decomposed.  Second,  existing  legacy  systems 
are  explored  in  order  to  discover  parts  to  be 
reused  as  services.  Third,  business  goals  are 
taken  into  account  to  complete  the  identifica¬ 
tion  of  services.  The  first  and  the  third  ideas 
are  reflected  in  our  approach.  Also,  our  ap¬ 
proach  supports  the  service  identification  by 
the  proven  method  of  feature-oriented  analy¬ 
sis  and  design  and  thus  puts  additional  struc¬ 
ture  on  the  method. 

The  approach  of  IBM  further  suggests  or¬ 
ganizing  services  in  a  hierarchy  of  services  of 
different  granularity.  By  comparison,  our  ap¬ 
proach  adds  the  dedicated  layer  of  molecular 
services  that  fonn  reusable  assets  in  the  spe¬ 
cific  domain.  According  to  the  respective  do¬ 
main,  the  molecules  would  be  composed  in 
different  ways  to  optimally  fit  the  requirement 
of  reuse.  Thus,  reuse  becomes  easier  by  only 
selecting  from  a  rather  small  number  of  assets 
with  well-tailored  granularity.  Additionally, 
the  concept  of  flows  of  services  is  mentioned 
to  be  important  in  [4];  however,  there  are  no 
details  about  the  identification  or  specification 
of  these  flows.  On  the  other  hand,  our  ap¬ 
proach  incorporates  the  defined  molecular 
services  as  the  building  blocks  with  which  to 
orchestrate  workflows. 

Another  approach  of  using  feature -oriented 
analysis  to  identify  services  for  an  SO  system 
is  described  in  [6].  Their  main  focus  is  on 
reengineering  towards  SO  systems.  They 
claim  to  do  a  feature  analysis  of  the  particular 
system  and  use  the  result  as  input  for  the  ser¬ 
vice  identification.  Yet,  they  do  not  provide 


concrete  guidelines  on  how  to  come  up  with 
services  of  the  right  granularity. 

While  methods  for  the  identification  of  or¬ 
chestrations  of  services  are  hard  to  find,  there 
are  a  number  of  languages  to  express  such 
orchestrations.  For  instance,  in  the  field  of 
Web  Services,  BPEL4WS  (Business  Process 
Execution  Language  for  Web  Services)  [7]  is 
widely  used  to  realize  SO  systems.  It  repre¬ 
sents  a  language  to  specify  orchestrations  of 
services  that  are  then  accessible  as  higher- 
level  services.  While  BPEL  is  well-suited  for 
the  pure  orchestration  of  services,  it  has  some 
deficiencies  in  the  area  of  business  processes 
that  comprise  human  interaction  during  the 
business  process.  We  addressed  this  by  com¬ 
bining  ideas  from  workflow-management, 
which  is  explicitly  designed  for  human  inter¬ 
action,  and  service  orientation.  Thus,  in  our 
approach,  orchestrated  services  are  described 
as  workflows. 

A  further  concept  we  transferred  to  service 
composition  is  “Design  by  Contract”  [8].  We 
enriched  the  composition  language  and  ser¬ 
vice  description  by  pre/post  conditions  and 
invariants  that  can  be  automatically  verified. 
Hence,  the  reliability  of  service-composition, 
static  as  well  as  dynamic,  can  be  improved  by 
checking  the  correct  usage  of  services.  The 
reusability  of  services  is  also  improved  with 
advanced  description,  since  automatic  checks 
can  reduce  the  number  of  feasible  candidate 
services,  which  makes  selection  easier. 

D.6  CONCLUSION 

We  have  transferred  product  line  technol¬ 
ogy  into  industry  since  1998,  and  we’ve  ex¬ 
perienced  in  nearly  all  cases  a  quick  increase 
of  the  number  features,  as  well  as  required 
variants.  Hence,  the  management  of  features 
and  their  variations  becomes  soon  one  of  the 
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major  challenges  in  maintaining  and  evolving 
viable  reuse  infrastructures.  The  environment 
and  context  of  service-oriented  systems  is 
typically  very  dynamic  and  always  distrib¬ 
uted.  Our  experience  with  such  service- 
oriented  product  lines  has  shown  that  the 
challenge  of  managing  variations  and  keeping 
services  reusable  and  useful  over  a  long  pe¬ 
riod  of  time  is  even  bigger  than  for  other  sys¬ 
tems. 

In  this  position  paper,  we  propose  an  ap¬ 
proach  that  alleviates  this  difficulty  through 
the  grouping  of  features  into  feature  binding 
units  of  the  same  binding  time,  as  well  as  by 
interpreting  these  units  as  key  drivers  for 
identifying  reusable  services,  that  is,  molecu¬ 
lar  services. 

The  practical  applications  of  our  approach 
in  our  lab  infrastructure  demonstrated  that 
product  line  technology  can  significantly  help 
in  mastering  this  challenge.  The  key  property 
of  the  approach  is  its  support  for  identifying 
reusable  services  at  the  right  level  of  granular¬ 
ity  abstraction. 

Nevertheless,  our  approach  is  still  in  an 
early  phase,  where  its  fundamental  properties 
are  worked  out  in  detail,  as  well  as  validated 
in  small  case  studies  in  our  prototyping  envi¬ 
ronments.  Currently,  we  have  established  a 
demonstration  facility  within  our  institute  to 
execute  real  scenarios  of  a  virtual  office  of  the 
future.  The  infrastructure  of  this  demonstra¬ 
tion  facility  has  been  defined  by  following  our 
approach,  which  has  already  provided  useful 
conceptual  insights  and  lessons  learned  from 
a  practitioner’s  perspective. 

Additionally,  we  are  working  on  complet¬ 
ing  the  approach  to  fully  cover  the  overall 
product  line  life  cycle  including  the  evolution 
of  product  line  infrastructures.  As  part  of 
these  activities,  an  architectural  prototype 
emulating  an  SO  environment  was  built  and 
has  been  used  to  refine  the  architectural  styles 


and  patterns  required  to  prepare  the  SO  para¬ 
digm  for  practical  contexts. 
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Abstract 

A  software  product  line  is  a  paradigm  to  develop  a  family 
of  software  products  with  the  goal  of  reuse.  In  this  paper,  we 
focus  on  a  scenario  in  which  different  products  from  differ¬ 
ent  product  lines  are  combined  together  in  a  third  product 
line  to  yield  more  elaborate  products,  i.  e. ,  a  product  line 
consumes  products  from  third  product  line  suppliers.  The 
issue  is  not  how  different  products  can  be  produced  sepa¬ 
rately,  but  how  they  can  be  combined  together.  We  propose 
a  sen’ice-oriented  architecture  where  product  lines  are  re¬ 
garded  as  services,  yielding  a  service-oriented  product  line. 
This  paper  illustrates  the  approach  with  an  example  for  a 
service-oriented  architecture  of  Web  Portals  and  Portlets. 


E.1  Introduction 

The  goal  of  a  software  product  line  is  to  produce  a  set  of 
distinct  but  similar  products.  Typically,  this  is  achieved  by 
reusing  a  common  product  line  infrastructure,  which  con¬ 
sists  not  only  of  traditional  reusable  software  (e.g.,  code, 
models,  documentation,  etc),  but  contains  product  line  spe¬ 
cific  assets  as  well  (e.g.,  feature  model,  production  plan, 
product  line  architecture,  etc). 

Currently,  software  product  lines  are  primarily  targeted 
at  producing  software  products  that  are  used  in  isolation. 
They  can  depend  on  third-party  software  (e.g.,  operating 
system,  embedded  system,  or  web  container),  but  this  third- 
party  software  is  usually  regarded  as  fixed  because  it  is  con¬ 
sidered  to  be  part  of  the  execution  environment.  So,  they 
do  not  depend  on  other  software  developed  by  third-party 
product  lines. 

Service-Oriented  Architectures  (SOAs)  may  change  this 
scenario.  Typically,  an  SOA  application  comprises  a  set 
of  third-party  services,  which  may  be  distributed.  Each 
of  such  services  supplies  some  specific  functionality,  and 
all  together  complete  the  distributed  application  function¬ 
ality  (i.e.,  the  web  services  with  fine-grained  functionality 


are  combined  together  to  serve  an  application  with  coarse¬ 
grained  functionality).  SOA  promotes  services  to  be  eas¬ 
ily  consumed  by  diverse  applications  because  the  discovery 
and  consumption  of  services  are  standardized.  The  useful¬ 
ness  of  SOA  rests  on  existing  standardization  efforts  and 
tooling  [16]. 

Reusing  services  can  even  be  ameliorated  by  creating  a 
product  line  that  satisfies  diverse  variability  requirements 
from  different  customer  applications  (e.g.,  a  product  line 
of  customized  portlets  for  customer  portals  where  existing 
techniques  are  used  [10,  18]).  This  way,  not  only  the  ap¬ 
plication  interface  is  customized  by  using  standards  to  con¬ 
sume  supplied  services,  but  also  the  application  function¬ 
ality  is  customized  by  using  product  lines  of  supplied  ser¬ 
vices. 

However,  the  entire  SOA  application  itself  could  require 
its  customization  (e.g.,  not  only  the  portlet  is  customized 
from  a  product  line,  but  the  portal  as  well).  When  the  SOA 
application  itself  turns  into  a  product  line,  a  new  scenario 
emerges.  This  scenario  requires  that  a  product  line  con¬ 
sumes  products  that  are  supplied  from  third-party  product 
lines.  We  call  such  a  scenario  a  Service-Oriented  Product 
Line  (SOPL). 

This  situation  is  well  known  in  real  industrial  assembly 
lines.  Consider  a  carmaker  with  an  assembly  line  (e.g.,  from 
the  chassis  to  the  end-product)  where  third-party  supplied 
components  provided  by  other  product  lines  are  assembled 
together.  These  non-trivial  components  are  the  engine,  the 
gear,  the  front-end,  etc,  which  are  also  customized  products 
of  other  product  lines.  In  this  case,  there  is  a  product  line  of 
cars  that  is  supplied  by  other  product  lines  of  components. 

Although  this  context  seems  futuristic  for  traditional 
software  at  first,  it  occurs  for  example  when  developing 
software  for  consumer  electronics  (e.g,  several  compo¬ 
nents  like  TV  receiver  with  different  options  are  built  into 
a  TV  product  line)  [19].  Here,  product  populations  offer 
an  architecture-centric  approach  to  combine  multiple  prod¬ 
uct  lines  where  human  intervention  is  required  [19].  Our 
work  strives  to  homogenize  the  combination  of  products 
from  product  lines  using  SOA.  This  reduces  human  inter- 
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vention  during  product  line  discovery  and  minimizes  human 
intervention  from  consumption.  This  way,  the  challenge  is 
how  to  enable  the  automatic  consumptions  of  products  from 
a  third-party  product  line,  which  we  address  in  this  paper. 

E.2  Service-Oriented  Product  Lines 

There  is  nothing  new  about  how  multiple,  distribute  and 
heterogenous  product  lines  are  developed  in  isolation,  i.e., 
existing  techniques  can  be  used  to  create  an  individual 
SOPL.  It  is  even  possible  for  a  product  line  to  manually 
supply  a  product  to  a  product  line  (e.g.,  when  2  products 
from  product  lines  are  manually  combined  together).  We 
envisage  SOPL  towards  the  automation  of  multiple  product 
lines  combination. 

The  issue  of  how  that  product  is  coupled  into  the  whole 
end-product  is  faced  by  product  populations,  which  de¬ 
scribe  an  architecture-centric  approach  to  attain  this  cou¬ 
pling  [19]  (see  Section  E-5).  This  approach  requires 
uman  intervention. 

We  envisage  for  SOPL  to  compose  products  supplied 
from  different  product  lines  with  little  human  intervention. 
To  this  end,  several  issues  should  be  addressed.  We  have 
to  (i)  describe  a  supplier  product  line,  (ii)  sketch  how  to 
consume  products  supplied  by  other  product  lines,  (Hi)  es¬ 
tablish  the  operation  of  SOPL  where  performance,  produc¬ 
tion  schedule,  bill  of  materials  and  other  elements  should 
be  considered  beforehand,  and  (iv)  adequate  existing  tool 
support. 

E.2.1  Supplier 

First  we  need  to  analyze  which  information  a  supplier 
product  line  should  publish  in  order  to  enable  its  automatic 
consumption  afterwards.  A  supplier  is  characterized  by  (i) 
descriptive  information,  (ii)  product  information,  and  (Hi)  a 
production  interface. 

-  Descriptive  information  refers  to  the  id,  name,  and  a 
brief  description  of  the  product  line.  This  information 
is  later  used  during  the  discovery  and  registration  of 
the  product  line. 

-  Product  information  describes  how  products  are  dis¬ 
tinguished  in  a  product  line  setting.  A  product  is  fre¬ 
quently  characterized  by  its  features.  This  is  the  basic 
specification  we  need  to  build  a  product.  Further  in¬ 
formation  about  core  assets  may  be  offered  as  well  for 
descriptive  purposes. 

-  Production  interface  consists  first  of  information  such 
as  production  time,  delivery  time,  average  product 
cost,  average  product  LOC,  average  product  size,  and 
so  on.  An  importantpiece  of  information  is  that  related 


to  the  interface  for  consumption  (e.g.,  which  URL 
should  be  invoked  in  the  case  of  a  web  service  and 
which  parameters  used).  This  information  would  be 
useful  when  choosing  among  concurrent  product  lines. 

Starting  from  this  information  provided  by  a  supplier,  a  con¬ 
sumer  might  consume  such  a  supplier  product  line. 

E.2. 2  Consumer 

A  consumer  product  line  demands  products  from  third- 
party  product  lines.  This  demand  is  specified  in  terms  of 
supplier's  characteristics  (e.g.,  descriptive  information).  . 
The  purpose  of  a  consumer  product  line  is  to  effectively  en¬ 
able  the  access  to  a  supplier.  Each  consumer  product  line 
is  realized  by  a  consumer  stub,  which  links  with  its  corre¬ 
sponding  product  line  supplier.  In  SOA  terms,  a  supplier  is 
supplying  services,  and  the  consumer  aggregates  services  to 
offer  an  application. 

Nonetheless,  our  aim  is  not  only  to  consume  a  single  sup¬ 
plier,  but  to  consume  multiple  supplier  product  lines.  This 
can  be  achieved  by  combining  a  set  of  consumer  product 
lines  together.  So,  a  set  of  consumer  stubs  can  be  used  to¬ 
gether.  When  they  are  used  to  create  another  product- line, 
this  idea  can  be  regarded  as  an  SOPL. 

This  combination  of  consumers  exposes  an  entire  SOPL 
architecture  representing  all  the  product  line  suppliers  in¬ 
volved.  We  envisage  SOPL  for  automating  the  operation  of 
the  entire  product  line. 

E.2. 3  Operation 

We  define  a  sequence  of  operations  between  the  con¬ 
sumer  and  their  suppliers  in  order  to  enable  their  commu¬ 
nication.  This  is  roughly  divided  into  registration  and  con¬ 
sumption  (see  Figure  E-l). 

Registration  The  registration  requires  the  discovery  of 
each  product  line  supplier  (i.e.,  human  intervention  is  re¬ 
quired)1.  Figure  E-l  shows  how  a  consumer  can  register  to 
an  individual  supplier  product  line  where  PL_A  registers  to 
PL_1.  The  sequence  of  operations  involves  first  a  getSer- 
viceDescriptionf)  call.  Then,  a  registerf)  operation  estab¬ 
lishes  a  relationship  for  future  consumptions  in  which  the 
supplier  provides  average  production  time,  delivery  time, 
etc.  The  general  case  would  encompass  registrations  with 
several  suppliers. 

Consumption  The  consumption  refers  to  the  production 
and  delivery  of  the  product.  In  general,  when  the  product 
line  production  or  derivation  process  is  automated,  we  can 

Existing  UDDIstandard  (for  web-services)  can  be  used  in  this  context 
(http://www.uddi.org/). 
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Figure  E-2:  Portal  /  Portlet  Architecture 


Supplier* 


T 


I 


Figure  E-1:  Operation  -  Sequence  Diagram 


invoke  such  product  line  specifying  desired  features  and  get 
a  product  [2,  6] . 

Figure  E-1  shows  the  sequence  of  operations  where  a  sup- 
plyProdfii  t()  calls  for  the  production  and  delivery  of  a  spe¬ 
cific  Product  (e.g.,  A1  from PL_1  in  Figure  E-3).  The  supplied 
product  is  considered  as  a  reusable  asset  by  the  product  line 
consumer.  Nonetheless,  tool  support  is  needed  to  automate 
such  consumption. 


Consumer 
(A2!  (AS; 
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Figure  E-3:  SO  PL  Scenario 


E.2.4  Tool  Support 

The  ideas  presented  before  on  consumer/supplier  rela¬ 
tionship  benefit  from  SOA  ideas.  More  to  the  point,  existing 
SOA  standardization  efforts  and  tool  support  may  readily 
enable  to  create  such  infrastructure. 

In  general,  we  envisage  two  kinds  of  consumptions. 
First,  when  the  product  lines  are  in  the  same  workspace 
(same  vendors),  this  is  named  internal  consumption.  Sec¬ 
ond,  when  the  product  lines  are  indistinct  workspaces  (dis¬ 
tinct  vendors),  this  is  named  external  consumption.  So  far, 
we  created  initial  tool  support  for  the  internal  consumption 
(not  detailed),  and  are  planning  to  work  on  external. 

E.3  Example 


provides  centralized  access  to  a  variety  of  services  [8],  An 
increasing  number  of  these  services  are  not  offered  by  the 
portal  itself,  but  by  a  third-party  component  called  a  portlet, 
which  is  a  presentation  oriented  web  service  [12,  15]. 

Figure  E-2  depicts  a  3-tier  architecture  for  portlets,  where 
MyBrowser  accesses  the  Portal _1  page  through  FLTTP.  Por¬ 
tal _1  is  hosted  by  Consumer 1  and  consists  of  a  layout  ag¬ 
gregating  the  Alpha ,  Beta,  and  Delta  portlets  that  are  hosted 
by  different  producers  (a.k.a.  suppliers). 

When  a  family  of  similar  portals  (e.g.,  research  group 
sites)  is  required,  a  customized  portal  can  be  the  outcome 
of  a  product  line  that  consumes  portlets  that  are  supplied  by 
third-party  product  lines.  Figure  E-2  shows  this  where  Por- 
tal_2  consists  of  a  version  of  Alpha  different  of  that  used 
by  Portal_l  (same  holds  for  Beta),  and  other  portlets  (e.g., 
Lamnda,  Theta).  This  setting  is  commonplace  in  SOA. 


Portals  and  Portlets  We  choose  portals  of  portlets  to  il-  Scenario  As  a  specific  example,  consider  an  SOPL  on  a 

lustrate  the  idea  of  SOPL  [  10].  A  portal  is  a  Web  page  that  product-line  of  enterprise  Web  portals  where  different  ser- 
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vices  are  offered.  Each  company  demands  a  similar,  but 
different  version.  So,  there  is  a  family  of  products.  The 
services  in  this  portal  are  offered  by  portlets  (e.g.  meeting 
room  reservation,  calendar,  hotel  reservation,  flight  reser¬ 
vation,  etc),  which  as  well  vary  and  hence  come  from  a 
product-line. 

Figure  E-3  sketches  our  motivating  scenario  for  a  set  of 
product  lines  of  portlets,  which  supply  to  a  product  line  of 
portals.  PL_A  is  the  product  line  of  enterprise  portals.  This 
product  line  uses  several  portlets  (from  A1  to  A6).  Note  that 
some  of  them  (A1  and  A4)  are  directly  supplied  by  third- 
party  product  lines.  A1  is  a  meeting-room  reservation  port- 
let  supplied  from  PL_1  product  line  while  A 4  comes  from 
PL_2  product  line,  which  offers  flight  reservation  function¬ 
ality.  A1  and  A 4  are  actually  portlets  that  are  integrated  into 
the  entire  portal2. 

A  mechanism  is  needed  for  each  product  line  supplier  to 
receive  the  product  configuration  as  input  (e.g.,  selection  of 
product  features  [2,  7]),  and  manufacture  as  output  the  final 
product3. 

The  challenge  of  SOPL  is  to  consume  products  that  are 
supplied  by  PL_1  and  PL_2  as  composable  artifacts  in  the 
PL_A  product  line  (i.e.,  invoking  third-party  product  lines 
and  obtaining  the  product  as  a  reusable  asset  for  another 
product  line).  We  believe  that  existing  SOA  tool  support 
provides  an  adequate  foundation  for  SOPL. 

E.4  Discussion 

Consistency  Products  to  be  reused  within  a  consumer 
product  line  need  to  fit  precisely.  Hence,  the  consistency 
is  crucial  to  assure  that  the  product  fits  as  artifact  of  a  larger 
product.  This  consistency  issue  appears  when  features  from 
a  consumer  require  to  be  propagated  to  a  supplier  (e.g.,  the 
features  from  supplier  should  be  consistent  with  the  product 
features  where  it  is  to  be  aggregated4).  It  is  not  trivial  how 
to  do  so  as  different  names  could  designate  same  function¬ 
ality  and  viceversa.  Similarly,  when  dealing  with  heteroge¬ 
neous  product  lines  (e.g.,  products  implemented  in  different 
platforms)  consistency  issues  may  appear  as  well. 

Production  Production  does  not  only  depend  on  product 
line  artifacts,  but  also  depends  on  third-party  artifacts.  If 
these  artifacts  are  not  available  within  schedule,  the  product 
would  not  be  produced.  Hence,  production  schedule  and 

2This  does  not  preclude  that  the  portlet  is  physically  deployed  on  the 
same  machine  than  the  portal,  but  can  be  deployed  externally,  and  reused 
solely  by  this  specific  portal. 

3Such  manufacturing  (e.g.,  portlet  product  lines  PL_1  and  PL_2)  in¬ 
volves  to  (i)  compose  taiget  product  code,  (ii)  compile  the  resulting  com¬ 
position,  (iii)  create  a  Portlet  bundle,  and  (iv)  deploy  it  to  a  given  location. 

4This  refers  to  a  feature  model,  whose  terminal  features  are  replaced 

with  an  entire  feature  model  [1,7]. 


timing  should  be  carefully  planned.  Otherwise,  undesirable 
production  bottlenecks  would  appear  in  the  performance. 

Orchestration  Consistency  and  timing  issues  are  symp¬ 
tomatic  of  a  more  general  issue,  which  is  orchestration  (i.e., 
how  different  product  lines  are  smoothly  orchestrated  to¬ 
gether).  Doing  so,  consistency,  time  and  production  issues 
could  be  considered.  To  attain  this,  experience  from  “real- 
world”  manufacturing  seems  beneficial  for  production  ex¬ 
periences.  Business  Process  Execution  Language  (BPEL) 
is  a  case  in  point5. 

Service-Oriented  Refactoring  The  idea  of  SOPL  to 
yield  a  product  is  backed  by  a  non-trivial  SOA  scenario. 
However,  the  use  of  multiple  product  lines  is  not  restricted 
to  this  case.  Consider  an  individual  product  line,  which  has 
grown  along  the  time  into  a  large  product  line.  When  this 
occurs,  both  technical  and  organizational  management  of 
the  product  line  becomes  intricate  (e.g.,  core  assets  man¬ 
agement,  production  planning,  etc).  There  is  an  ancient 
principle  to  face  this:  “ divide  and  conquer”  (a.k.a.  sepa¬ 
ration  of  concerns  in  software  engineering).  Applying  such 
principle  leads  us  to  divide  an  original  product  line  into  a  set 
of  product  lines .  This  refactoring  of  an  original  product  line 
into  a  set  of  product  lines  would  enable  eventually  to  ease 
the  product  line  management  (as  they  are  smaller).  This 
refactoring  is  also  motivated  when  the  newly  created  prod¬ 
uct  line  is  to  supply  products  to  new  customers  that  demand 
only  restricted  functionality  (i.e.,  fewer  than  original  prod¬ 
uct  line  functionality).  Therefore,  we  envisage  that  several 
situations  would  demand  service-oriented  refactoring. 

E.5  Related  Work 

As  industrialization  of  the  automobile  manufacturing 
process  led  to  increased  productivity  and  higher  quality  at 
lower  costs,  industrialization  of  the  software  development 
process  is  leading  to  the  same  advantages  [11],  A  software 
factory6  is  defined  as  "a  facility  that  assembles  (not  codes) 
software  applications  to  conform  to  a  specification  follow¬ 
ing  a  strict  methodology" .  In  general,  to  set-up  a  factory 
is  to  create  a  production  capability.  An  important  piece  of 
work  is  how  such  factories  connect  with  third-party  facto¬ 
ries. 

In  a  product  line  setting,  a  factory  uses  a  production  plan, 
which  is  “a  description  of  how  core  assets  are  to  be  used 

5BPEL  is  a  business  process  language  that  grew  out  of  WSFL  and 
XLANG.  It  is  serialized  in  XML  and  aims  to  enable  programming  in  the 
large.  The  concepts  of  programming  in  the  large  and  programming  in  the 
small  distinguish  between  two  aspects  of  writing  the  type  of  long-running 
asynchronous  processes  that  one  typically  sees  in  business  processes  (from 
http://en  .wildpedia.org/wiki/BPEL) . 

6http://en  .wikipedia.org/wiki/Software_factoiy 
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to  de\’elop  a  product  in  a  product  line ”  [4].  A  production 
plan  describes  how  a  product  is  developed  [3,  4,  14].  Lee  et 
al.  describe  an  approach  for  production  planning  based  on 
features  [13].  Recently,  Wangetal.  describe  production  “on 
the  fly  ”  where  dynamic  reconfiguration  was  used  to  support 
privacy  in  web  applications  [21]. 

Consider  a  typical  production  plan  that  implies  the  selec¬ 
tion  of  product  desired  features  in  order  to  compose  such  se¬ 
lected  features  [9].  Then,  when  the  raw  compound  product 
is  obtained,  it  is  necessary  to  create  a  binary  (e.g.,  an  exe¬ 
cutable,  a  JAR  or  a  WAR).  To  this  end,  the  raw  data  is  compiled 
packaged,  and  deployed.  Optionally,  it  may  be  measured, 
tested,  versioned  or  even  documentation  created.  In  gen¬ 
eral,  it  describes  how  the  factory  operates  the  reusable  ar¬ 
tifacts  [17].  Such  production  techniques  reuse  not  only  the 
artifacts,  but  even  the  process  that  are  present  in  the  product 
line  infrastructure.  However,  they  do  not  enable  to  invoke  a 
third-party  product  line  and  reuse  the  third-party  product. 

The  notion  of  product  populations  is  not  far  from  SOPL. 
The  difference  stems  from  the  fact  that  product  populations 
focus  on  how  a  product  is  integrated  into  a  product  line  (i.e., 
the  architectural  interfaces  that  glue  them  together)  [  19,  20]. 
This  work  focuses  on  the  automation  of  this  combination 
rather  than  on  how  products  are  glued  together. 

Product  line  products  are  usually  produced  reusing  a 
common  infrastructure.  This  infrastructure  is  usually  in¬ 
ternal  to  the  product  line.  Even  though  there  is  experience 
with  COTS  components  [5] ,  they  are  not  part  of  a  product 
line.  Hence,  to  the  best  of  our  knowledge,  we  are  unaware 
of  tooling  to  enable  the  automated  consumption  of  aproduct 
line  supplier. 

E.6  Conclusions 

This  paper  presents  our  ongoing  work  on  the  vision 
of  SOPL,  which  consume  products  from  supplier  product 
lines.  We  motivated  our  idea  with  an  example  for  a  product 
line  of  portals  consuming  supplier  product  lines  of  portlets. 
We  introduced  preliminar  representations  for  consumer  and 
supplier  product  lines,  described  the  basic  operation  with 
registration  and  consumption,  and  sketch  the  initial  tool 
support  required. 

SOPLs  rely  on  SOA  for  product  line  production.  To  an¬ 
swer  the  workshop  question,  existing  SOA  techniques  are 
used  to  build  more  complex  SPL  systems.  Our  longstand¬ 
ing  aim  is  to  facilitate  the  emergence  of  a  concurrent  market 
where  atomic  products  from  supplier  product  lines  can  be 
automatically  integrated  into  a  product  line. 
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